1. Orientering og introduksjon
1.1. Innledning
Dette dokumentet er en generell overbygning over de enkelte FKB-produktspesifikasjonene og angir generelle mekanismer i FKB og hvordan de forskjellige delene av spesifikasjonen skal sees i sammenheng.
1.2. Definisjon av Felles KartdataBase (FKB)
FKB er en samling datasett som utgjør en sentral del av grunnkartet
1.3. Formål med FKB
FKB er grunnleggende geografisk informasjon for å utøve lov- og forskriftsbelagte saker og ta gode beslutninger. FKB kan brukes til:
-
å kjenne seg igjen ute i terrenget
-
forvaltningsmessig saksbehandling i kommuner, statlige etater og ledningsetater
-
saksbehandling knyttet til plan- og bygningsloven med forskrifter (jf. [PBL-KART])
-
prosjekteringsformål
-
analyse og presentasjon i et integrert informasjonssystem (GIS-system)
-
produksjon av kart og avledede produkter med forskjellig krav til innhold, detaljering og stedfestingsnøyaktighet FKB inngår i det offentlige kartgrunnlaget ([DOK]).
1.4. Ansvar for FKB
FKB er spesifisert i FKB produktspesifikasjoner. Geovekst-samarbeidet har ansvar for utvikling av disse spesifikasjonene. Dette gjøres i nært samarbeid med kommunene utenfor Geovekst, andre brukere, produsenter og systemleverandører. Geovekst-forum har ansvar for å iverksette arbeid for å utarbeide nye eller revidere FKB-spesifikasjoner og vedtar FKB produktspesifikasjonene.
Det meste av etableringen av FKB-data skjer også gjennom Geovekst-samarbeidet og rettighetshavere vil da være Geovekst-partene. For enkelte områder vil FKB-data være etablert utenfor Geovekst og har andre eier- og rettighetsforhold.
Se mer om Geovekst-samarbeidet på Kartverkets hjemmesider.
1.5. Kriterier for FKB
Ved vurdering av hvilke datasett/objekter som skal inngå i FKB er følgende kriterier viktige:
-
FKB-data skal være vektordata
-
FKB-data skal ha et etablert forvaltningsopplegg (FDV)
-
FKB-data skal normalt ha en homogen nasjonal dekning
-
FKB-data skal normalt ikke være sikkerhetsgraderte data
-
FKB-data skal normalt være topografiske/fysiske data (grunnkart/basisdata)
-
Data som bare er interessante for en etat/part vil normalt ikke inngå i FKB
1.6. Geovekst-data - fullstendighet, kvalitet og rettslig gyldighet
FKB-data, ortofoto og laserdata (Geovekst-data) som selges gjennom kommunen eller Kartverkets forhandlere er etablert og finansiert gjennom Geovekst-samarbeidet eller kommunene alene for kommuner utenfor Geovekst-samarbeidet. Disse er også rettighetshavere til dataene.
Geovekst-dataene er de mest detaljerte og best oppdaterte geodataene som er tilgjengelig. Dataene skal gi en best mulig gjengivelse av terrenget og menneskeskapte objekter med varierende innhold, detaljering og nøyaktighet. Det skjer kontinuerlig endringer i terrenget (flom, ras, brann m.m.), objekter bygges og fjernes, så det kan ikke forventes at alle områder til enhver tid er 100% oppdaterte.
Datasettene kan derfor ha varierende fullstendighet og kvalitet. Brukere som har spesielle krav til dette, MÅ undersøke fullstendighet og kvalitet før bruk.
Geovekst-dataene er ikke rettslig gyldige.
2. Historikk og status
De første versjonene av FKB produktspesfikasjon oppsto samtidig med Geovekst-samarbeidet tidlig på 1990-tallet. Datainnholdet ble i tidlig fase utformet slik at det skulle tilsvare datainnholdet i Teknisk kartverk 1:1000 (TK) og Økonomisk Kartverk 1:5000 (ØK). Senere har det kommet større og mindre revisjoner med jevne mellomrom. Her listes ut noen av de store oppdateringene:
-
1995: FKB 2.2
-
2003: FKB 3.3
-
2007: FKB 4.0
-
2016: FKB 4.6
Fram til innføring av FKB 4.0 ble FKB regnet som en produktspesifikasjon. Ved innføring av FKB 4.0 ble de ulike datasettene i FKB skilt ut som egne produktspesifikasjoner og dokumentet FKB generell del (dette dokumentet) ble etablert for å beskrive de felles rammene for FKB-produktspesfikasjonene.
For komplett oversikt over endringer mellom tidligere versjoner henvises det til endringslogg i de enkelte versjonene.
2.1. Endringslogg
2.1.1. Endringer fra FKB 5.0.1 2023-01-01 til FKB 5.1 2024-07-01
-
Nytt kapittel 1.6 om fullstendighet, kvalitet og rettslig gyldighet for Geovekst-data
-
Oppdatert tabell 1 (kapittel 6.1) med referanser til oppdaterte FKB produktspesifikasjoner og fotogrammetriske registreringsinstrukser
-
Endret kapittelstruktur og navn under kapittel 6.2 og oppdatert av høydegrunnlag i kap 6.2.2
-
Oppdatert beskrivelse av modellering av assosiasjoner i FKB i kap 7.1.3
-
Lagt inn referanse til produktspesifikasjon AvvikKartdata 1.0 i kapittel 8.4
-
Lagt inn generelle retningslinjer for fotogrammetrisk datafangst av FKB som vedlegg D
-
Standarden finnes kun på HTML-format
2.1.2. Endringer fra FKB 5.0 2022-01-01 til FKB 5.0.1 2023-01-01
Oppdatert tabell 1 (kapittel 6.1) med referanser til oppdaterte FKB produktspesifikasjoner og fotogrammetriske registreringsinstrukser
2.1.3. Endringer fra FKB 4.6 2020-01-01 til FKB 5.0 2022-01-01
Punktene under beskriver de største endringene i FKB 5.0 sammenlignet med FKB 4.6 2020-01-01.
Håndtering av kodelister:
Alle kodelister i FKB 5.0 forvaltes i Geonorge kodelisteregister. Se mer om rammer for bruk av kodelister i FKB under Kodelister.
Assosiasjoner:
Det er åpnet for at vanlige assosiasjoner kan tas i bruk til å beskrive andre typer sammenhenger mellom objekter enn å beskrive flategeometri. F.eks. at et Bygning-objekt vet hvilke Veranda-objekter som "tilhører" bygget. Assosiasjonene modelleres i tråd med reglene i SOSI del 1 Regler for UML-modellering [SOSI-UML]. Se mer om rammer for bruk av assosiasjoner i FKB under Assosiasjoner.
Flategeometri:
Tidligere versjoner av FKB har basert seg på SOSI-formatets flategeometri som innebærer at alle flateobjekttyper må avgrenses av en eller flere avgrensningsobjekter og skal ha et representasjonspunkt. Dette er nå endret slik at flater som hovedregel modelleres med heleid geometri og uten representasjonspunkt. Der det er behov skal det likevel fortsatt modelleres representasjonspunkt og settes krav til sammenheng mellom flategeometrien og geometrien til egne avgrensningsobjekter. Dette modelleres som en assosiasjon etter gitte regler. Se nærmere beskrivelse under Flategeometri.
Id-håndtering; Identifikasjon av objektene i FKB og pekere til Id-er i eksterne systemer:
Regler for bruk av identifikasjon er presisert og pekere til eksterne systemer i form av URI-er [URI] er lagt inn på en lang rekke nye objekttyper. Les mer under Identifikasjon av objekter i FKB.
Endringer i fellesegenskaper:
Det er gjort noen justeringer i fellesegenskapene i FKB Generell del, dvs. hvilke egenskaper som er lovlig å benytte på objektene i FKB. Følgende endringer er gjort:
-
Datatypen posisjonskvalitet er endret. Den største endringen er at kodeliste målemetode er erstattet av den enklere datafangstmetode. I tillegg er nøyaktighet endret fra påkrevd til opsjonell og definisjoner etc. er gjennomgått og presisert.
-
Egenskapen registreringsversjon er endret fra å være definert som en datatype til å bli en kodeliste.
-
Egenskapene kopidata og prosesshistorie er ikke lenger definert som del av fellesegenskapene som skal brukes ved forvaltning av FKB.
-
Egenskapen sluttdato er lagt til som en del av fellesegenskapene. Denne er en egenskap som i likhet med oppdateringsdato styres av forvaltningssytemet og den er lagt til for å kunne støtte utveksling av data fra historiske spørringer. Egenskapen skal normalt ikke inngå i en leveranse av levende FKB-data (sluttdato vil da ikke ha noen verdi).
Oppdatert kvalitetsmodell:
Modell for å beskrive krav til kvalitet og dokumentere kvalitet på FKB-data er oppdatert. Ny modell baserer seg mer direkte på standarden Geodatakvalitet [G], noe som blant annet medfører at det i FKB 5.0 settes krav til både systematiske og tilfeldige avvik. Se mer under Kvalitet.
Endret dokumentasjon:
Dokumentasjon av FKB produktspesifikasjon er totalt omarbeidet slik at det nå er HTML som er standardformatet (fortsatt med PDF som et alternativ). Dette bør gjøre det lettere å hoppe mellom de ulike delene av FKB produktspesifikasjonene. Nytt format og nye verktøy gjør at ganske mye av dokumentasjonen er omarbeidet. Det er imidlertid forsøkt å gjenbruke innholdet mest mulig. Der det er vesentlige endringer i innholdet skal dette være beskrevet i endringsloggen for det enkelte FKB-datasett.
2.2. Revisjon
FKB produktspesifikasjonene oppdateres ved behov. Hver enkelt FKB produktspesifikasjon kan oppdateres uavhengig av de andre. De generelle retningslinjene for FKB (dette dokumentet) vil normalt oppdateres ved hver oppdatering av et underkapittel.
Hver enkelt FKB produktspesifikasjonen skal oppdateres maksimalt 1 gang pr. år og ny versjon utgis fortrinnsvis ved nyttår.
En versjon av et FKB-kapittel identifiseres ved et versjonsnummer. Dette nummeret er knyttet til datamodellen (objektkatalogen/applikasjonsskjema). I tillegg kan det utgis revisjoner av FKB-kapitler som ikke innebærer endring i objektkatalog (for eksempel presiseringer i registreringsinstruks for fotogrammetrisk kartlegging). Disse revisjonene merkes da med ny dato, men ikke nytt versjonsnummer.
3. Omfang
3.1. Dokumentet omfatter
Dette dokumentet beskriver generelle og prinsipielle forhold som er felles for alle FKB produktspesifikasjonene.
3.2. Bruksområde for dokumentet
Dette dokumentet er en viktig referanse for de enkelte FKB produktspesifikasjonene. Mange av begrepene/konseptene som benyttes i FKB forklares i dette dokumentet.
4. Normative referanser
Det er nødvendig å ha kjennskap til dokumentene under for fullt ut å forstå denne produktspesifikasjonen.
[GEO-VEIL] : Geovekst veiledingsdokumentasjon
[ISO-METADATA] : 19115-1:2015 Geographic information - Metadata - Part 1: Fundamentals og 19115-2:2015 Geographic information - Metadata - Part 2: Extensions for acquisition and processing
[PBL-KART] : Veiledning til forskrift om kart, stedfestet informasjon, arealformål og digitalt planregister
[SOSI-UML] : SOSI Regler for UML-modellering, versjon 5.1 2020
[SOSI-FORMAT] : SOSI Realisering i SOSI-format, versjon 5.0 2018
[SOSI-GML] : SOSI Realisering i GML-format, versjon 5.0 2018
5. Definisjoner og forkortelser
5.1. Definisjoner
korrigering av innholdet i geodataene slik at de fremstiller de faktiske forhold på et gitt tidspunkt, etter de retningslinjer som gjelder for innhold og kvalitet [PABG]
informasjonsmodellene i SOSI-modellregister er modellert som UML-modeller. UML-modellen for et FKB-datasett benevnes som et UML-applikasjonsskjema. Fra UML-applikasjonsskjema kan det automatisk genereres et GML-applikasjonsskjema som beskriver hvordan dataene representeres som GML [SOSI-UML].
MERKNAD: Se objektkatalog
MERKNAD: Se veileder for å lese UML-diagrammer
bearbeidede primærdata tilpasset et bestemt bruksområde [FKB]
MERKNAD: Avledede data skal i prinsippet ikke ajourføres direkte, men ajourføringen skal komme gjennom automatisk utvelgelse og generalisering fra primærdata. I noen tilfeller vil dette være en for tung prosess slik at en må avvike fra hovedprinsippet. Kalles også generalisert datasett.
EKSEMPEL: N5 Kartdata (avledet/generalisert produkt fra FKB-data).
Detaljerte geodata som beskriver det fysiske landskapet ved naturlige eller menneskeskapte objekter. Basisdata brukes til lokalisering og som underlag for temadata. [FKB]
MERKNAD: basis geodata er synonymt med begrepet grunnkart (eller grunnkartdata)
identifiserbar samling av beslektede data [G]
navngitt kjennetegn eller karakteristikk av et objekt
uttrykk for hvor godt egenskapsdataene beskriver de aktuelle egenskapene [G]
UML-modellelement for å modellere geografiske objekttyper [SOSI-UML].
MERKNAD: Begrepet brukes i mange sammenhenger synonymt med objekttype. Se også veileder for å lese UML-diagrammer.
FKB-data som er etablert ved fotogrammetrisk kartlegging [FKB]
MERKNAD: I Fotogrammetrisk FKB inngår også enkelte objekttyper som ikke registreres fotogrammetrisk. Eksempel er fiktive avgrensningslinjer og representasjonspunkt.
Grunnkart er et begrep som er synonymt med basis geodata. Se definisjon under basis geodata.
MERKNAD: Grunnkart brukes til flere formål og kan danne grunnlag for avledede kart i forskjellige målestokker. Grunnkartet skal være det kartgrunnlaget som skal tjene alle formål som omhandles i plan- og bygningsloven eller dens forskrifter.
uttrykk for i hvilken grad spesifiserte deler av et produkt finnes i det aktuelle datasettet [G]
MERKNAD: Fullstendighet karakteriseres ved kvalitetsmålene manglende objekter, overskytende objekter (ønsket om fullstendige geodatabaser innebærer også at det er galt dersom det finnes objekter i databasene som ikke skal være der i henhold til spesifikasjonene) og manglende egenskaper. Fullstendighet kan angis i prosent i relasjon til spesifiserte krav. Informasjon om fullstendighet må være datert.
stedfestet informasjon [G]
MERKNAD: Geodata består av objektidentifikasjon og informasjon om stedfesting og egenskaper. Stedfestingsdataene på sin side kan omfatte både posisjonsdata og geometriske beskrivelsesdata.
generalisert avbildning av geografiske objekter med deres romlige relasjoner; med angitt geodetisk datum, projeksjon og koordinatsystem, samt målestokk dersom avbildningen er analog [G]
geodata tilrettelagt for presentasjon av kart [PABG]
fortløpende ajourføring basert på rapportering fra forvaltningsrutiner, daglige arbeidsrutiner og samarbeidsparter [PABG]
MERKNAD: Kalles også administrativt vedlikehold. Data som samles inn administrativt, kan være digitale stikningsdata eller data fra sluttkontroll av beliggenhet, markmålte bygninger, senterpunkt bygning, situasjonsplan og melding om landbruksbygg.
i hvilken grad en samling av iboende egenskaper oppfyller krav [G]
MERKNAD: Se standarden Geodatakvalitet for en nærmere beskrivelse av datakvalitet.
hvor godt regler som finnes i spesifikasjonene er oppfylt [G]
MERKNAD: Logisk konsistens betegner sammenhengen mellom produktet og reglene produktet skal oppfylle. Logisk konsistens kan altså måles uten at en kjenner noen "fasit".
informasjon som beskriver et datasett [G]
MERKNAD: Hvilke opplysninger som inngår i metadataene, kan variere avhengig av datasettets karakter. Vanlige opplysninger er innhold, kvalitet, tilstand, struktur, format, produsent og vedlikeholdsansvar.
mål for en estimert verdis nærhet til sin sanne verdi eller til det man antar er den sanne verdi [G]
MERKNAD: I standarden Geodatakvalitet er de ulike nøyaktighetsmålene beskrevet.
forekomst (instans) av en objekttype [SOSI-UML]
definisjon og beskrivelse av objekttyper, objektegenskaper samt relasjoner mellom objekter, sammen med eventuelle funksjoner som er anvendt for objektet. [SOSI-UML]
geografisk objekttype er en klasse av objekter med felles egenskaper, forholdet mot andre objekttyper og funksjoner [SOSI-UML]
EKSEMPEL: Eksempler på objekttyper er Takkant, Arealbruksgrense og Mønelinje.
arealinndeling basert på krav til detaljering/nøyaktighet av basis geodata i området [FKB]
MERKNAD: I FKB brukes områdetypen til å si noe om hvilken FKB-standard som bør velges i området. Områdetype brukes også som styrende for krav i standardene "Plassering og beliggenhetskontroll" og "Stedfesting av matrikkelenhets- og råderettsgrenser".
forbedring av den datatekniske kvaliteten av eksisterende data [PABG]
ajourføring som utføres systematisk med jevne mellomrom [PABG]
MERKNAD: Ved periodisk ajourføring blir eksisterende data, enten de har vært gjennom kontinuerlig ajourføring eller ei, kontrollert og evt. forbedret, og manglende objekter blir supplert. Objekter som ikke er endret, blir ikke kartlagt på nytt. Etter periodisk ajourføring skal datasettene minimum tilfredsstille kvalitetskravene for den valgte FKB-standard i området. Det kan være nødvendig også med en oppgradering for å oppfylle kvalitetskravene. Periodisk ajourføring gjøres vanligvis ved fotogrammetri.
tilleggsdata til FKB som er nødvendige for å formidle en god presentasjon uten at de opprinnelige datasettene blir berørt [FKB]
MERKNAD: Presentasjonsdata lages for presentasjoner i ulike målestokker. Det genereres presentasjonsdata for å ha mulighet til blant annet å redigere, avblende/slette, skrive om eller flytte tekster og symboler i kartbildet, uten at datasettene blir berørt.
EKSEMPEL: Eksempler på presentasjonsdata er tekstdata generert fra datasett der tekst, tall eller symboler er ferdig plassert i kartbildet. En annen type presentasjonsdata er avblendingspolygoner som brukes til å fjerne unødig mye data i et aktuelt kartbilde.
et definert geodatasett som består av de mest detaljerte og nøyaktige data innen et definert område, har en viss utbredelse og jevnlig blir produsert og/eller ajourholdt [G]
MERKNAD: Primærdatasett skal være presentasjons- og produktuavhengige. De skal kunne danne utgangspunkt for forskjellig bruk og forskjellige produkter. Det er derfor krav om en viss utbredelse og produksjon før en kan kalle et datasett for primærdatasett. Primærdatasett er i prinsippet uavhengige datasett (ikke avledet fra andre datasett) og ajourholdes uavhengig av andre datasett. Et objekt tilhører bare ett primærdatasett.
detaljert beskrivelse av ett datasett eller en serie med datasett med tilleggsinformasjon som gjør det mulig å produsere, distribuere og bruke datasettet av andre (tredjepart) [SOSI-KRAV]
MERKNAD: En dataproduktspesifikasjon kan lages for produksjon, salg, sluttbrukervirksomhet eller annet.
statistisk størrelse som angir spredningen for en gruppe måle- eller beregningsverdier i forhold til deres sanne eller estimerte verdier [G]
beskrivelse av sammenhengen mellom geografiske objekter [G]
MERKNAD: De aktuelle objektene har ofte en fysisk sammenheng. Topologi er de av objektenes egenskaper som overlever det som er kalt kontinuerlige transformasjoner (også kalt gummiduk-transformasjoner). Alle tallverdier (lengder, arealer og retninger) kan bli forandret, mens for eksempel naboskapsforhold vil være uendret.
5.2. Forkortelser
AR5: Arealressurskart i målestokk 1:5000
DOK: Det offentlige kartgrunnlaget. DOK er offentlige geografiske data som er tilrettelagt for kommunenes plan- og byggesaksarbeid. DOK er definert i [PBL-KART].
DTM: Digital TerrengModell.
ESRI fgdb: Leveranseformatet ESRI filgeodatabase (ESRI = Enviromental Systems Research Institute)
Georef: Metadataregister for Geovekst-data. Tilgjengelig som et datasett på Geonorge.
Geovekst: Geodatasamarbeid mellom de nasjonale partene KS (kommunesektorens organisasjon, omfatter både kommuner og fylkeskommuner), Energi Norge, Kartverket, Telenor, Statens vegvesen, Landbruksdepartementet og Norges vassdrags- og energidirektorat. Lokalt kan Geovekst-samarbeidet også ha andre parter.
GML: Geography Markup Language – Internasjonalt standardformat for utveksling av geografisk informasjon (OpenGIS® Geograph Markup Language (GML) Encoding Standard)
JSON: JavaScript Object Notation. Generelt tekstbasert utvekslingsformat som er mye brukt på nett og som også kan brukes for geografiske data. GeoJSON er en praktisk rettet spesifikasjon for å uttrykke geografiske data med vha. JSON.
NGIS: Nasjonalt Geografisk informasjonssystem. En generell modellbasert forvaltningsplattform for felles forvaltning av geografiske data i en sentral base gjennom åpne API-er som blant annet brukes i Sentral FKB. NGIS-OpenAPI er det nye grensesnittet for oppdatering av NGIS.
NRL: Nasjonalt register for luftfartshindre
NVDB: Nasjonal vegdatabank. Forvaltningsløsning for vegnettet og tilhørende informasjon eid av Statens vegvesen.
OCL: Object Constraint Language. Språk som brukes til å formulere krav/restriksjoner til modellelementene i UML.
PBL: Plan- og bygningsloven.
UML: Unified Modelling Language. Modelleringsspråk som (blant annet) brukes til å beskrive geografiske informasjonsmodeller.
URI: Uniform Resource Identifier. Kompakt streng av tegn som identifiserer en abstrakt eller fysisk ressurs.
UUID: Universally unique identifier. 128-bit globalt unik streng av tegn som kan genereres automatisk av en datamaskin.
WFS: Web Feature Service. Standard fra OGC (Open Geospatial Consortium) for å sende geografiske data over nett. WFS-T (T = Transaction) er en utvidelse for å sende endringer/transaksjonsdata.
6. Generelt om FKB
6.1. FKB-datasett
FKB-datasett | Versjon | Forvaltning | Registreringsinstruks |
---|---|---|---|
5.1 |
Sentral FKB |
Ikke aktuelt |
|
5.0.2 |
Sentral FKB |
||
5.0.1 |
Sentral FKB |
||
5.1 |
Sentral FKB |
||
5.1 |
Sentral FKB |
||
5.0.3 |
Sentral FKB |
||
5.1 |
Sentral FKB |
||
5.0.2 |
Sentral FKB |
||
5.0.1 |
Sentral FKB |
||
5.1 |
Sentral FKB |
Ikke aktuelt |
|
5.0 |
Sentral FKB |
||
5.1 |
Sentral FKB |
||
5.1 |
Sentral FKB |
||
Elveg (vegnett) (følger bare delvis reglene for resten av FKB) |
NVDB (med oppdatering fra kommunene gjennom Sentral FKB. Det jobbes med å ferdigstille produktspesifikasjonen NVDB Vegnett Plus som skal ta over for ELveg 2.0 i denne sammenhengen) |
6.2. Detaljeringsgrad og datainnhold i FKB
6.2.1. Områdetyper og FKB kartleggingsstandarder
Det viktigste prinsippet i FKB er at en søker å kartlegge det samme området kun en gang, og at en kan benytte etablerte data til ulike formål. Dette kan for eksempel være kartproduksjon eller mer intelligente analysefunksjoner.
Behovene for FKB-data i en kommune varierer avhengig av hvilke formål datasettene skal brukes til. I FKB er det spesifisert FKB-standarder (FKB-A, FKB-B, FKB-C og FKB-D) som skal dekke behovet for felles kartdata i kommunens ulike områdetyper.
Detaljinnhold og stedfestingsnøyaktighet i FKB varierer i de ulike standardene, med størst detaljering og stedfestingsnøyaktighet i A-standarden og minst i D-standarden. Inndelingen i FKB-standarder setter krav til minimum detaljeringsgrad og stedfestingsnøyaktighet.
De ulike standarder kan benyttes slik at det for eksempel innen en kommune dannes et lappeteppe der flere av standardene er i bruk. Dette gir et datagrunnlag som er tilpasset behovet for felles kartdata i de ulike områdene av kommunen. Hvert enkelt (del)område kan bare være tilordnet en standard. Områdeinndelingen i en kommune vil kunne endre seg i takt med nye utbyggingsaktiviteter.
I praktisk vedlikehold av FKB kan det være aktuelt med forenklinger og varierende kompleksitet avhengig av de behov brukerne har. For delområder vil det for eksempel kunne være aktuelt å velge høyere standard enn det som gjelder for områdetypen generelt, for eksempel et hyttefelt i et fjellområde. Behov og ønsker hos brukerne er ofte relatert til kostnader, og kostnader er igjen relatert til metoder for datafangst etc. Det er derfor naturlig at brukeren definerer krav til innhold og krav til FKB-data som etableres.
Gjennom Geovekst-samarbeidet avgjøres i fellesskap hvilken FKB-standard som skal brukes i et område, og kartleggingskostnadene fordeles ut fra en kost/nytte vurdering. Dersom det er en part som har behov for kart med større detaljering og/eller bedre kvalitet enn de andre, vil denne parten måtte ta en større del av kartleggingskostnaden.
Kommunen har et spesielt ansvar for å påse at det er en tilstrekkelig kartleggingsstandard i kommunen til å utføre planleggingsoppgaver i kommunens ulike områdetyper.
FKB-standard | Områdetype | Beskrivelse |
---|---|---|
FKB-A / FKB-B |
Områdetype 1 |
Byområde. Dette vil som regel være sentrale byområder og tettsteder med høy grad av utnytting eller svært høy grunnverdi. |
FKB-B |
Områdetype 2 |
Tettbygd/utbyggingsområder. Dette vil være områder som i kommuneplanen er eller forutsettes disponert til tettsteds- og utbyggingsformål og som ikke omfattes av områdetype 1. |
FKB-B / FKB-C |
Områdetype 3 |
Spredtbygd/dyrket mark/skog. Dette vil være områder som i kommuneplanen er eller forutsettes disponert til jordbruk eller skogbruk og spredt bebyggelse. |
FKB-D |
Områdetype 4 |
Områder med liten eller ingen bebyggelse. Dette vil være den delen av kommunen som har en ekstensiv arealutnytting og lav grunnverdi: som regel fjellområder eller tilsvarende lite produktive arealer. |
6.2.1.1. FKB-A-standard
Bruksområde:
Bruksområder for A-standarden er spesielt innenfor plan og prosjektering i byområder og tettsteder med høy utnyttelsesgrad, der kravet til detaljering, fullstendighet og stedfestingsnøyaktighet er meget stort. Data etablert etter A-standarden skal kunne benyttes som grunnlagsdata i en 3D (by)modell. A-standarden er aktuell som grunnlag for analyse og forvaltningsoppgaver for de mest intensive byområder og tettsteder med høy utnyttelsesgrad.
FKB-A-data kan benyttes til uttegning av detaljerte kart (målestokk 1:1000 eller bedre), samt utarbeidelse av produkter i målestokk 1:5000 som for eksempel N5 Raster og N5 Kartdata.
Detaljering:
FKB-A er en meget detaljert standard med detaljert registrering av bygninger (arker, verandaer, trapper mv) og med detaljert registrering av høyder på oppstikkende objekter (hus, mur, gjerde, mast med videre). Høydereferansen på objektene er vanligvis topp, mens detaljert terrenggrunnlag gir fothøyden til objektene.
Etableringsmetode:
Storparten av A-dataene etableres fotogrammetrisk (kartkonstruksjon fra flybilder med oppløsning ca 5–8 cm).
For en del datasett vil A-dataene bli samlet inn fra andre kilder. Dette medfører at disse objektene kan ha dårligere eller bedre stedfestingsnøyaktighet enn det som generelt gjelder for A-standarden.
6.2.1.2. FKB-B-standard
Bruksområde:
B-standarden benyttes i områder med tettbebyggelse og blandet bebyggelse, utbyggingsområder og langs større veger (europa-, riks- og fylkesveger). Denne standarden bør benyttes for de fleste områder utenfor byene der det finnes en viss mengde bygninger og tekniske installasjoner. B-standarden kan benyttes til detaljprosjektering og ved utarbeidelse av reguleringsplaner, men har enkelte begrensninger i forhold til A-standarden. B-standarden kan benyttes som grunnlagsdata for utarbeidelse av 3D-modeller, men disse vil ikke være like detaljert som i A-standarden.
FKB-B-data kan benyttes til uttegning av detaljerte kart (målestokk 1:1000 eller bedre), samt utarbeidelse av produkter i målestokk 1:5000 som for eksempel N5 Raster og N5 Kartdata.
Detaljering:
FKB-B er en detaljert standard med registrering av bygningsdetaljer (arker, verandaer, trapper med videre) og detaljert registrering av høyder på oppstikkende objekter (bygning, mur, gjerde, mast med videre). Høydereferansen på objektene er vanligvis topp, mens detaljert terrenggrunnlag gir fothøyden til objektene. Forskjellen på B-standard og A-standard er i hovedsak at det er større minstemål på objekter før de skal registreres i B-standarden.
Etableringsmetode:
Storparten av B-dataene etableres fotogrammetrisk (kartkonstruksjon fra flybilder med oppløsning ca 8–12cm). For en del datasett vil B-dataene kunne bli samlet inn fra andre kilder. Dette medfører at disse objektene kan ha dårligere eller bedre stedfestingsnøyaktighet enn det som generelt gjelder for B-standarden.
6.2.1.3. FKB-C-Standard
Bruksområde:
C-standarden benyttes i spredt bebygde og ubebygde områder. C-standarden har begrensninger innenfor utarbeidelse av reguleringsplaner, situasjonsplaner og byggeplaner og skal ikke etableres i områder der det er naturlig å etablere FKB-data etter B-standarden. C-standarden kan benyttes som grunnlagsdata for utarbeidelse av enkle 3D-modeller.
FKB-C kan benyttes til utarbeidelse av N5-produkter som for eksempel N5 Raster og N5 Kartdata
Detaljering:
FKB-C inneholder bygningers hovedform og de dominerende detaljene i topografien forøvrig. En del mindre detaljer registreres ikke i FKB-C og minstemål for registering er større enn i FKB A-B. Historisk ble detaljeringen i FKB-C utformet slik at den tilsvarte det tidligere økonomiske kartverket (ØK).
Etableringsmetode:
Storparten av C-dataene etableres fotogrammetrisk (kartkonstruksjon fra flybilder med oppløsning ca 15-25 cm). For en del datasett vil C-dataene kunne bli samlet inn fra andre kilder. Dette medfører at disse objektene kan ha dårligere eller bedre stedfestingsnøyaktighet enn det som generelt gjelder for C-standarden.
6.2.1.4. FKB-D-standard
Bruksområde:
D-standarden benyttes i områder med liten eller ingen bebyggelse (stort sett fjellområder). For å få heldekkende FKB-datasett for en kommune skal D-områdene fylles med data. Dette for å få landsdekkende data slik at vi ikke får ”hvite hull” i datasettene.
Etablering og detaljering:
For FKB-D data etablert tidligere vil detaljering i hovedsak være lik N50 Kartdata for vann, høyde, stier, traktorveger og bygningsmessige anlegg. Ved nyere etablering fra omløpsfoto vil D-standarden i hovedsak være lik C-standarden. Innholdet vil imidlertid variere fra datasett til datasett.
Datasett | Innhold |
---|---|
AR5 |
Flater med kode "Ikke kartlagt". NIBIO jobber med å fylle AR5 med et forenklet innhold fra skogressurskart (SR16) også i D-områder. |
Høydekurve |
Høydekurver avledet fra laserskanning eller etablert ved bildematching fra omløpsfoto i NDH-prosjektet. 1m ekvidistanse der det er utført laserskanning og 5m ekvidistanse i områder der det er utført bildematching. Gamle fotogrammetriske kurver kan fortsatt finnes igjen i enkeltområder. |
Vegnett |
Hentes fra NVDB. Samme innhold uavhengig av FKB-standard. |
Tiltak |
Samme innhold uavhengig av FKB-standard. Lite aktuelt i D-områder. |
Vann |
Eksisterende data er hovedsaklig likt N50 i detaljering og innhold. Ved nykonstruksjon er standarden lik C-standarden, med unntak for minstestørrelser for ElvBekk, KanalGrøft og Innsjø. |
TraktorvegSti |
Traktorveger og stier har i utmarksområder et forvaltningsopplegg som i stor grad baserer seg på andre datakilder enn fotogrammetri. Bl.a. samordning med N50 og friluftsruter. Datainnholdet er i stor grad uavhengig av FKB-standard. |
Øvrige FKB-datasett |
Lik C-standarden. Forskjellen ligger i at det er færre objekter å kartlegge i D-områder. Områder der det finnes menneskeskapte objekter av et visst omfang er i all hovedsak definert som FKB-C områder. |
6.2.2. Høydegrunnlag i FKB
Med unntak av FKB-AR5 kartlegges alle FKB-data med høydeverdier på objektene. FKB-data er såkalt 2.5D. Kravene til nøyaktighet for registrering av høydeverdiene på objektene følger også av valgt FKB-standard. I de fleste tilfeller registeres høyden på toppen av objektet, men avvik fra dette kan angis ved hjelp av egenskapen høydereferanse.
I tillegg inneholder FKB datasettet FKB-Høydekurve som beskriver terrengoverflaten. Dette datasettet er hovedsakelig avledet/generert fra Nasjonal Detaljert Høydemodell (NDH) og forholder seg derfor ikke til inndelingen i FKB-standarder på samme måte som andre FKB-datasett. NDH inneholder punktskyer fra laserskanning i de fleste områder, men noen områder med lite vegetasjon (høyfjellsområder) har terrengmodeller basert på bildematching fra flybilder med oppløsning 25 cm (omløpsfoto). Ved laserskanning gjennom NDH-prosjektet og Geovekst er leveranse av genererte høydekurver med 1m ekvidistanse basert på terrengmodellene standard. For områder der terrengmodellen er basert på bildematching genereres høydekurver med 5m ekvidistanse. Disse kurvene forvaltes i FKB-Høydekurve. Gamle høydekurver basert på fotogrammetrisk datafangst kan fremdeles finnes i enkelte områder.
Ved større terrenginngrep anbefales det at det gjøres ny laserskanning og at FKB-Høydekurve oppdateres med bakgrunn i oppdaterte sensordata. I påvente av nye høydekurver anbefales det at man fjerner høydekurvene i områder der man vet at terrenget er endret slik at FKB-Høydekurve ikke gir feilaktig informasjon.
For å få den mest detaljerte terrenginformasjonen bør terrengmodellene fra Høydedata.no brukes direkte og ikke de avleda høydekurvene i FKB.
6.3. Uavhengige primærdatasett
FKB bygger i utgangspunktet på prinsippet om uavhengige primærdatasett. Med dette menes at primærdatasettene ikke er avledet fra andre datasett og ajourføres uavhengig av andre datasett. Hvert primærdatasett kan på denne måten leve atskilt fra andre datasett. Et objekt skal kun tilhøre ett primærdatasett.
Uavhengige primærdatasett er nyttig fordi de ulike datasettene vedlikeholdes av ulike instanser, til ulik tid og med ulike verktøy. Dette gir en effektiv dataforvaltning, men gir også muligheter for inkonsistens mellom datasettene. Det er derfor viktig at det kjøres konsistenskontroller mellom FKB-datasettene (og ev. andre datakilder).
Merknad: Prinsippet om uavhengige datasett blir ikke etterlevd fullt ut. Mange objekter forvaltes av praktiske/tekniske/organisatoriske årsaker i flere systemer. Dette er likevel et godt prinsipp for å få til effektiv dataforvaltning og som det bør være et mål å etterstrebe ved modellering og forvaltning av FKB-data.
6.4. Identifikasjon av objekter i FKB
6.4.1. Unik identifikasjon av kartobjektene i FKB
Alle kartobjekter i FKB har en unik identifikator i form av datatypen Identifikasjon. Identifikasjon er en datatype som består av navnerom, lokalid og versjonid. For FKB-data er lokalid på formen UUID [UUID]. Dette innebærer at lokalid-en alene alltid er globalt unik. Identifikasjon er modellert som en del av fellesegenskapene i FKB. Se detaljer om dette under kapittel 7.
Logikken rundt identifisering og håndtering av unike objekter i FKB konsentrerer seg om håndtering av egenskapen lokalid. Ved bruk av FKB-data skal man forholde seg til lokalid som den egenskapen som identifiserer hvert kartobjekt i FKB unikt. Både NGIS-OpenAPI og Geosynkronisering-API baserer seg på lokalid til å identifisere transaksjoner på objekter i FKB. Når FKB-data utveksles på GML-format skal GML-id til objektene inneholde lokalid.
Det er vesentlig å presisere at identifikasjon på kartobjektene i FKB nettopp identifiserer et kartobjekt og ikke det fysiske objektet som kartobjektet representerer. Det kan oppstå nye/endra kartobjekter som representerer det samme fysiske objektet og man bør derfor være forsiktig med å knytte informasjon om det fysiske objektet til den unike identifikatoren i FKB. I slike sammenhenger bør man i stedet benytte en tematisk identifikator som f.eks. bygningsnummer for objekttype Bygning.
Regler for håndtering av lokalid:
FKB inneholder mange typer data og det er vanskelig å lage detaljerte regler for håndtering av identifikasjon i forbindelse med geometrioperasjoner som gjelder generelt for FKB. Noen overordna føringer gjelder likevel:
-
Nye kartobjekter: Det genereres en ny lokalid til objektet
-
Endring av et objekt (egenskaper og/eller geometri): Lokalid beholdes (versjonid oppdateres).
-
Endring av objekttype på et objekt er et spesialtilfelle. Dette håndteres som at et objekt av den gamle objekttypen slettes og at et objekt av den nye objekttypen etableres (lokalid beholdes ikke, se regler under).
-
-
Sletting av objekt: Objektet (inkl. lokalid) slettes. Nye objekter som oppstår skal ikke gjenbruke en lokalid som allerede er brukt/slettet
-
Splitting av et objekt: Håndteres som ett endret objekt (lokalid beholdes) og ett nytt objekt (ny lokalid)
-
Sammenføying av to objekter: Håndteres som ett endret objekt (lokalid beholdes) og ett slettet objekt
Dersom det finnes egenskaper på kartobjektene som er knyttet til det fysiske objektet (f.eks. bygningsnummer i FKB-Bygning) så må det lages rutiner som sikrer at denne informasjonen tas vare på gjennom av alle typer endringer i kartobjektene. Den generelle transaksjonslogikken i FKB vil ikke automatisk håndtere dette. Les mer om dette under Koblingsnøkler til andre data.
Alternativ håndtering av lokalid:
Det absolutte kravet i FKB er at situasjonen etter transaksjonen er komplett/riktig. I noen tilfeller er det lite hensiktsmessig/meningsfullt å beholde lokalid ved splitting/sammenføying av objekter. Dette kan f.eks. være ved ajourhold av FKB-AR5 (eller andre datasett) der det er vanskelig å knytte et kartobjekt til et spesifikt objekt i terrenget. I slike tilfeller kan man velge en alternativ håndtering ved splitting/sammenføying:
-
Splitting av objekt: Håndteres som ett slettet objekt og to nye objekter (to nye lokalid-er)
-
Sammenføying av objekt: Håndteres som to slettinger og ett nytt objekt (en ny lokalid).
Regler for håndtering av navnerom:
-
Navnerom identifiserer datasettet unikt og settes av forvaltningssystemet. Eks. http://data.geonorge.no/SFKB/FKB-Vann/so
Regler for håndtering av versjonid:
-
Versjonid settes lik tidspunkt for oppdatering av objektet i forvaltningsbasen. Dette styres også automatisk av forvaltningssystmet. Versjonid er nøkkelen ved historiske spørringer mot FKB-data.
-
I forvaltningsbasen vil versjonid ha lik verdi som oppdateringsdato. Les mer om dette under Oppdateringsdato
Les mer om håndtering av identifikasjon i i forvaltningssystemet NGIS/Sentral FKB.
6.4.2. Koblingsnøkler til andre data
Datasettene i FKB inneholder noen koblingsnøkler til tilsvarende objekt i andre databaser. Dette gjøres ved at det legges en egenskapsverdi som unikt identifiserer det tilsvarende objektet i det eksterne systemet inn på kartobjektet i FKB.
Koblingsnøkler til andre data gir mulighet til å koble FKB-data til andre typer data og gir brukeren vesentlig større nytteverdi. Å etablere koblingsnøkler slik som omtalt over kan være arbeidskrevende.
Koblingsnøkler gir også muligheter for å utføre automatisk feilsjekking av FKB-dataene mot de eksterne dataene. Når dette blir gjort, oppdages en god del feil som må rettes. Ved å ta belastningen ved å rette opp feil vil data imidlertid gi vesentlig sikrere bruk i den daglige forvaltning. Koblingsnøkler som skal opprettes i FKB, er spesifisert under det enkelte datasett.
Eksempel på godt etablerte koblinger fra FKB til andre systemer/databaser er:
-
Kobling mellom representasjonspunkt i bygninger i FKB og Matrikkel (koblingsnøkkel er bygningsnummer - bygningens unike identifikasjon).
-
Kobling mellom veglenker i vegnettet (Elveg 2.0) og FKB-TraktorvegSti og adressekode/navn i Matrikkelen (koblingsnøkkel er adressekode).
Eksterne pekere som URI:
Ved innføring av FKB 5.0 innføres mulighet for kobling mot andre systemer i form av URI-er [URI] for en rekke nye objekttyper. Eksempler på dette er:
-
nvdbpeker - egenskap der man kan legge inn en URI som peker på et unikt objekt i NVBD
-
nrlpeker - egenskap der man kan legge inn en URI som peker på et unikt objekt i NRL
-
eksternpeker - egenskap der man kan legge inn en URI som peker på et unikt objekt i et eksternt system (angitt av URI-en)
Det er ikke et krav om at URI-en skal peke til en åpen tjeneste som gir en presentasjon av objektet i det eksterne systemet, men bruken av URI-er åpner for at dette er mulig.
6.5. Bruk av datoegenskaper
Fellesegenskapene for FKB definerer hvilke datoegenskaper som skal benyttes i FKB. Se kapittel 7 for detaljer i hvordan det er modellert. Dette kapittelet beskriver detaljer for den praktiske bruken av datoegenskapene.
6.5.1. Datafangstdato
Datafangstdato angir dato for måling/observering/registrering av objektet (i terrenget).
-
Ved fotogrammetrisk datafangst vil dette være datoen for når flybildene som ligger til grunn for kartkonstruksjonen ble tatt (flyfotodato).
-
Ved digitalisering av eksisterende kart vil dette normalt være datoen for når flybildene kartene er produsert etter er tatt (flyfotodato).
-
Ved landmåling vil dette være datoen for innmåling.
Ukjent dato: Datafangstdato er påkrevd på alle objekter. For en del eldre data kan det være at objektene ikke er kodet med noen dato. Som dummyverdi for FKB-data skal 18000101 benyttes.
6.5.2. Verifiseringsdato
Verifiseringsdato angir dato for når det er fastslått at eksisterende dataobjekt fremdeles samsvarer med objektet i virkeligheten. Egenskapen brukes f.eks. i forbindelse med fotogrammetrisk ajourhold, og hvor det ikke er registrert endringer på objektet (det virkelige objektet er i samsvar med dataobjektet).
6.5.3. Oppdateringsdato
Oppdateringsdato er tidspunkt for oppdatering i forvaltningssystemet. Dette er en verdi som styres automatisk av forvaltningssystemet etter følgende regler:
-
Oppdateringsdato er datotid for oppdatering av databasen settes av forvaltningsbasen (ikke av klienten). For data i Sentral FKB vil verdien for oppdateringsdato samsvare med versjonid.
-
Oppdateringsdato skal endres også hvis det er kopidata som blir endret eller importert i en ”kopibase”. I en kopibase vil altså oppdateringsdato være oppdatert, mens versjonid fortsatt skal ha en verdi som beskriver tidspunkt for oppdatering i forvaltningsbasen.
-
Når avgrensingslinjene til en flate endres, skal flateobjektet få ny oppdateringsdato.
-
Oppdateringsdato skal endres hvis en egenskap endres.
6.5.4. Sluttdato
Sluttdato er tidspunkt for når versjonen av objektet ble erstattet eller opphørte å eksistere. Egenskapen styres av forvaltningssystemet. Sluttdato sendes bare med ut fra forvaltningssystemet ved historiske spørringer. For levende data vil ikke sluttdato ha noen verdi og egenskapen skal da heller ikke sendes med.
6.5.5. Praktisk bruk av datoegenskapene i forbindelse med ajourhold av FKB-data
Ved fotogrammetrisk ajourføring blir noen objekter registrert på nytt, noen får endret databeskrivelse, noen slettes, mens andre forblir uforandret. For påføring av de ulike datoegenskapene gjelder følgende ved en fullstendig fotogrammetrisk ajourføring:
-
Nye dataobjekter skal ha påført ny DATAFANGSTDATO (=flyfotodato for bildene som ligger til grunn for kartkonstruksjon).
-
Dataobjekter som fantes fra før i datasettet og det gjennom visuell inspeksjon blir verifisert at objektene fortsatt eksisterer uforandret i terrenget, skal beholde gammel DATAFANGSTDATO. I tillegg skal ny VERIFISERINGSDATO legges på objektet. Dette selv om man ikke har kontrollert at egenskapskodingen av objektet er riktig. Dersom det er dataobjekter som ikke synes i bildene, for eksempel på grunn av gjengroing, skygge i bildene eller overdekking, må det utøves skjønn. Enten vurderes det at dataobjektet fremdeles eksisterer uforandret (kodes som over) eller at det er borte (slettes). Dersom man er i stor tvil, skal dataobjektet beholdes uten påføring av verifiseringsdato.
-
Endrede dataobjekter skal ha påført ny DATAFANGSTDATO (=flyfotodato for bildene som ligger til grunn for endringen). Dersom det kun er deler av et objekt som er endret, splittes dataobjektet. Det samme gjelder for objekter som krysser prosjektavgrensningen. Den delen som er uforandret beholder DATAFANGSTDATO, men det settes på ny VERIFISERINGSDATO. Den delen av objektet som er endret får kun ny DATAFANGSTDATO.
-
Sletting av dataobjekter. Når objektet ikke fins i terrenget lenger, eller det vurderes til å ha blitt borte, skal det slettes fra FKB. I ajourholdsprosjekter vil det være en god ide å levere slettede objekter til oppdragsgiver. Typisk kan dette gjelde bygninger som ikke er merket som revet/brent, flyttet eller utgått i Matrikkelen.
6.6. Kodelister
Alle kodelister i FKB 5.0 forvaltes i Geonorge kodelisteregister. I UML-modellene ligger tomme kodelister med referanse (URL) til kodelistene i Geonorge. Dette innebærer at kodelistene i FKB kan endres uten at versjonsnummer på produktspesifikasjonene oppdateres. Systemer som forholder seg til FKB datamodellene må også forholde seg til Geonorge kodelisteregister.
Alle kodelister i Geonorge kodelisteregister inneholder 3 verdier: kodenavn, beskrivelse/definisjon og kodeverdi. Det er kodeverdiene som utveksles i dataene i alle formater, mens kodenavn og beskrivelse vil være det som presenteres for brukerne i de fleste tilfeller.
Retningslinjene for utforming av kodeverdier i FKB 5.0:
-
Kodeverdiene må være unike og teknisk enkle å utveksle/tolke. Det innebærer at norske tegn, skilletegn (bindestrek/underscore/mellomrom) og andre spesialtegn unngås. Som hovedregel brukes små bokstaver og ved sammensatte kodeverdier brukes stor bokstav på andre ledd ("NCName")
-
Kodeverdiene skal være kortest mulig (normalt under 10 tegn)
-
Kodeverdiene skal om mulig gi en intuitiv mening (en forkortet/sammentrekt versjon av kodenavn e.l.)
-
Etablerte kodeverdier (f.eks. i form av tallverdier) fra tidligere versjoner av FKB eller andre systemer som NVDB/Matrikkelen beholdes
Statuskoder i Geonorge kodelistergister:
-
Status Gyldig: Brukes for gyldige koder i FKB. Kun kodeverdier med status Gyldig skal brukes ved oppdateringer inn i FKB
-
Status Utgått og Erstattet: Brukes for koder som ikke lenger skal benyttes ved oppdateringer i FKB. Det kan likevel være mulig at eldre FKB-data har disse kodene.
-
Status Sendt inn, Ikke godkjent og Utkast: Brukes for koder som er foreslått brukt i FKB, men disse skal ikke benyttes før status ev. endres til Gyldig.
6.7. Vedlikehold
Hovedprinsippet for ajourføring av FKB-data er at utvalgte objekter og datasett skal ajourføres kontinuerlig gjennom daglige administrative rutiner, for eksempel byggesaksbehandling, eller ved rapportering fra samarbeidspartene. Fullstendighet og hurtig oppdatering av de viktigste objektene skal prioriteres fremfor stedfestingsnøyaktighet. Dette betyr at stedfestingsnøyaktighet i enkelte tilfeller kan bli dårligere enn kravet til aktuell FKB-standard. Det er imidlertid et krav at alle aktuelle objekter skal være kodet med opplysninger om datafangstmetode og stedfestingsnøyaktighet (..KVALITET).
Alle endringer vil ikke bli fanget opp gjennom administrative rutiner, og det vil derfor være nødvendig med periodisk ajourføring, der hele datasettet gjennomgås og bringes opp på et ajourført nivå tilsvarende som ved nykartlegging. Ved periodisk ajourføring skal data fra kontinuerlig ajourføring kontrolleres, eventuelt forbedres, manglende objekter skal suppleres og overskytende objekter skal slettes. Objekter som ikke er endret, blir ikke kartlagt på nytt. Hyppigheten av periodisk ajourhold varierer avhengig av områdetype og byggeaktivitet.
For mer informasjon om ajourføring av FKB-data henvises det til veilederen til standarden Produksjon av basis geodata [PABG] og Geovekst veiledningsdokumentasjon [GEO-VEIL]. Det henvises også til spesifikasjonen av datasettet FKB-Tiltak som handler om å fange opp objekter i kontinuerlig ajourhold gjennom saksbehandling.
6.8. Oppgradering
Med oppgradering menes forbedring av den datatekniske kvaliteten av eksisterende data.
Ved utgivelse av nye versjoner av Produktspesifikasjon for FKB må det vurderes i det enkelte tilfelle om og hvordan eldre FKB-data skal oppgraderes. Dette vil ofte være et økonomisk spørsmål. Data skal som minimum oppgraderes slik at de er kodet i henhold til gjeldende versjon av FKB. Eventuelle mangler i forhold til gjeldende versjon av FKB skal lagres som metadata.
Oppgradering av eldre FKB-data kan deles inn i tre hovedgrupper.
-
Oppdatering av koder til ny SOSI/FKB-versjon. Objekttyper og egenskaper skal omkodes til gjeldende versjon av SOSI/FKB. I en del tilfeller der man har eldre data kan det være aktuelt å ikke oppgradere dataene slik at de følger alle topologiske regler som er spesifisert i FKB.
-
Oppgradering av FKB-data fra 2 dimensjoner til 3 dimensjoner (med høyde). For data på terrenget som mangler høyde vil det være interessant å påføre høydeverdier fra terrengmodell. Dette kan gjøres i egne oppgraderingsprosjekter eller i forbindelse med periodisk ajourføring.
-
Konsistens mellom datasett. Enkelte FKB-data skal være koblet mot registerdatabaser. Forbedring av disse koblingene er aktuelt å gjøre som egne oppgraderingsjobber. Eksempel på en slik oppgraderingsjobb er ”husvask”. I ”husvask” kontrolleres at bygningspunkt i Matrikkel ligger inne i bygningskroppen.
6.9. Sømløse data
Mellom kommuner eller fylker:
FKB-data forvaltes i Sentral FKB. Prinsippet er at forvaltningsløsningen er satt opp mest mulig sømløs, men praktiske hensyn gjøre at noen datasett likevel er delt i kommunevise eller fylkesvise baser. Alle datasett er delt i sondedeler slik at kommunene oppdaterer direkte i sin lokale UTM-sone.
Ved deling i forskjellige forvaltningsbaser er det gjeldende administrative grense som brukes til avgrensning.
Mellom områdetyper/kartleggingsstandarder:
Forvaltningen skjer sømløst mellom kartleggingsstandardene (A-D). Det er kun kvalitetskodingen som angir at data har ulik stedfestingsnøyaktighet. Det er metadataregisteret Georef som angir gjeldende kartleggingsstandard. Georef er tilgjengelig som WMS-tjeneste, se informasjon på geonorge.no.
7. Modellering av FKB produktspesifikasjoner
FKB 5.0 skal generelt modelleres i henhold til reglene i SOSI Regler for UML-modellering versjon 5.1 [SOSI-UML]. I tillegg er det gjort noen presiseringer/innsnevringer for FKB som er beskrevet i dette kapittelet. FKB Generell del inneholder felles modelleringselementer (kodelister, datatyper og fellesegenskaper) som realiseres i de enkelte FKB produktspesifikasjonene.
7.1. Geometrimodell i FKB
7.1.1. Geometrityper
UML (ISO 19107) | SOSI Geometri | GML Geometri | JSON Geometri |
---|---|---|---|
GM_Point |
.PUNKT |
gml:Point |
point |
GM_Curve |
.KURVE |
gml:Curve |
linestring |
GM_Surface |
.FLATE |
gml:Surface |
polygon |
FKB-data skal ha en enklest mulig geometri. Andre geometrityper enn de som er angitt i tabellen over (som f.eks. multipoint, multicurve, multisurface etc.) skal ikke benyttes i FKB 5.1.
7.1.2. Flere geometrier
Hovedregel i FKB produktspesifikasjoner er at hver objekttype modelleres med en geometriegenskap. Det finnes imidlertid noen unntak fra denne hovedregelen. Se tabell under for mulige kombinasjoner av geometriegenskaper for objekttyper som er definert med mer enn en geometriegenskap i FKB:
Kombinasjon av geometriegenskaper | Beskrivelse | Eksempel |
---|---|---|
Påkrevd flategeometri og opsjonell punktgeometri |
Brukes for objekttyper med flategeometri for å gi mulighet til å utveksle representasjonspunkt for flategeometrien. Anbefales kun brukt der representasjonspunktet har en mening/funksjon. |
Objtype Arealressursflate |
Påkrevd punktgeometri og opsjonell flategeometri |
Brukes for objekttyper som alltid vil ha punktgeometri, men som også kan ha flaterepresentasjon. |
Objtype Bygning |
Opsjonell punktgeometri og opsjonell flategeometri (og en constraint som sier at en av dem skal finnes) |
Brukes for objekttyper som det i noen sammenhenger er naturlig å representere som punkt og i andre sammenhenger som flate (ut fra størrelse/detaljering etc). |
Objtype Pipe |
I alle disse kombinasjonene vil det være et krav om at punktgeometrien ligger innenfor flategeometrien. I GML-formatet vil disse dataene utveksles med flere geometriegenskaper. I SOSI-formatet vil de bare ha en geometri. Enten punktgeometri eller flategeometri - der punktgeometrien utveksles som representasjonspunkt i flaten.
7.1.3. Assosiasjoner
Kartobjektene i FKB er alltid selvstendige objekter som kan eksistere uavhengig av andre objekter. Assosiasjoner uttrykker generelt en eller annen sammenheng mellom to objekttyper/objekter. Et eksempel på dette kan være å uttrykke hvilke Veranda-objekter som tilhører hvilke Bygning-objekter. FKB 5.1 åpner for å benytte assosiasjoner i datamodellene etter følgende rammer:
-
Assosiasjoner modelleres som vanlige assosiasjoner i tråd med reglene i SOSI Regler for UML-modellering 5.1 [SOSI-UML]. Andre varianter av assosiasjoner som aggregering, komposisjon etc. benyttes ikke i FKB.
-
Assosiasjoner i FKB skal alltid modelleres mellom konkrete/instansierbare objekttyper (og altså ikke til/fra supertyper). Dette gjør det enklere å implementere assosiasjonene som koblingstabeller i geografiske databaser.
-
Assosiasjoner i FKB modelleres som hovedregel som enveis. Det vil si at de bare er navigerbare i en retning. (Eks: Bygningen vet hvilke verandaer som hører til bygget, men verandaen vet ikke hvilken bygning den tilhører)
-
Multiplisitet på den navigerbare enden skal alltid være 0..1 eller 0..*. (Dvs. at det at det finnes et objekt av en objekttype vil ikke medføre krav om at det må finnes et referert objekt av en annen type.)
-
Assosiasjonene modelleres slik at det settes krav til at de assosierte objektene utveksles som refererte objekter i GML (dvs. ved bruk av taggen inlineOrByReference=byReference i UML)
-
Dersom det benyttes assosiasjoner som er navigerbare i begge retninger så skal det være multiplisitet 0..1 i begge ender. (Dvs. at mange-til_mange-forhold unngås i FKB datamodeller)
Se eksempler på Utveksling av assosiasjoner på GML- og SOSI-format i Vedlegg C.
Hvilke avgrensningskurver som brukes til å avgrense et flateobjekt er en spesialvariant av assosiasjoner med egne krav. Dette er beskrevet nærmere under Modellering av flateobjekter
7.1.4. Flategeometri
7.1.4.1. To typer flateobjekter
Objekttyper i FKB med flategeometri deles i 2 typer:
Type | Beskrivelse | Flatereferanser | Eksempel |
---|---|---|---|
1 |
Der avgrensningsobjektene ikke har noen funksjon utover å avgrense flateobjektene ("simple-feature" flater) |
Ingen avgrensningsobjekter, ingen flatereferanser ("heleid geometri") |
Objekttype Brønn, Objekttype Industriområde |
2 |
Der det finnes egne avgrensningsobjekter og det er krav til sammenheng mellom flateobjektene og avgrensningsobjektene |
Flateobjektet vet hvilke avgrensningsobjekter som utgjør flateavgrensningen og retning og rekkefølge på disse objektene ("delt geometri") |
Objtype Bygning, Objtype Elv |
7.1.4.2. Modellering av flateobjekter
Hvilken av de 2 typene flater en objekttype er må man ta stilling til når man utarbeider FKB produktspesifikasjonen.
Det er lov (men ikke anbefalt) å modellere med opsjonell punktgeometri i tillegg til flategeometrien for å kunne utveksle representasjonspunkt for flater. Dette gjelder flater av både "Type 1" og "Type 2".
Dersom man skal modellere en objekttype av "Type 2" (med krav til sammenheng mellom flateobjekt og avgrensningsobjekter) gjelder følgende regler ved UML-modelleringen:
-
Det etableres en assosiasjon fra flateobjekttype (kilde) til avgrensningsobjekttype (mål)
-
Assosiasjonen skal være navigerbar fra kilde til mål (se pil i figuren over)
-
Assosiasjonen skal ha mulitiplisitet null-til-mange på mål-siden av assosiasjonen
-
Assosiasjonen skal ha rollenavn som starter med avgrensesAv på mål-siden (rollenavnene må være unike pr. flateobjekttype så dersom en flateobjekttype kan avgrenses av flere typer avgrensningsobjekter så legges avgrensningsobjekttype som postfiks i rollenavnet for å gjøre det unikt)
-
Flateobjekttypen skal ha restriksjon med denne beskrivelsen: "Område-geometrien skal være lik summen av geometriene til de assosierte avgrensningsobjektene"
Se eksempler på Utveksling av flategeometri på GML- og SOSI-format i Vedlegg C.
7.2. UML felleselementer til bruk i «ApplicationSchema» for FKB-datasett
Generelle klasser med fellesegenskaper som kan kopieres inn og benyttes i FKB produktspesifikasjoner.
7.2.1. Pakke: Generelle elementer
Definisjon: Pakke med modelleringselementer som benyttes i applikasjonsskjema for forvaltning av FKB
7.2.1.1. «FeatureType» Fellesegenskaper (abstrakt)
Definisjon: abstrakt objekttype som bærer sentrale egenskaper som er anbefalt for bruk i produktspesifikasjoner.
Egenskaper
Navn: |
identifikasjon |
Definisjon: |
unik identifikasjon av et objekt Merknad FKB: Unik identifikasjon av et objekt, ivaretas av den ansvarlige produsent/forvalter, og som kan benyttes av eksterne applikasjoner som referanse til objektet. Den unike identifikatoren er unik for kartobjektet og skal ikke endres i kartobjektets levetid. Dette må ikke forveksles med en tematisk identifikator (for eksempel bygningsnummer) som unikt identifiserer et objekt i virkeligheten. En bygning med samme bygningsnummer vil kunne representeres i mange kartprodukter der det finnes en unik identifikasjon i hver av dem. For FKB benyttes UUID (Universally unique identifier) som lokalId. Dette innebærer at lokalId alene alltid vil være unik. Likevel skal alltid navnerom også angis. Navnerom angir FKB-datasettet. |
Multiplisitet: |
[1..1] |
Type: |
|
Profilparametre i tagged values: |
SOSI_navn: IDENT |
Navn: |
oppdateringsdato |
Definisjon: |
tidspunkt for siste endring på objektet Merknad FKB: Denne datoen viser datasystemets siste endring på dataobjektet. Egenskapen settes av forvaltningssystemet etter følgende regler: i. Oppdateringsdato er tidspunkt for oppdatering av databasen og settes av forvaltningsbasen (ikke av klienten). ii. Oppdateringsdato skal endres også hvis det er kopidata som blir endret eller importert i en ”kopibase”. iii. Når avgrensingslinjene til en flate endres, skal flateobjektet få ny oppdateringsdato. iv. Oppdateringsdato skal endres hvis en egenskap endres. |
Multiplisitet: |
[1..1] |
Type: |
|
Profilparametre i tagged values: |
SOSI_datatype: DATOTID |
Navn: |
sluttdato |
Definisjon: |
Tid for når denne versjonen av objektet var erstattet eller opphørt å eksistere. Merknad FKB: Egenskapen settes av forvaltningssystemet. Sluttdato skal kun sendes med ut fra forvaltningssystemet i sammenhenger der objektenes historikk er interessant. |
Multiplisitet: |
[0..1] |
Type: |
|
Profilparametre i tagged values: |
SOSI_datatype: DATOTID |
Navn: |
datafangstdato |
Definisjon: |
dato når objektet siste gang ble registrert/observert/målt i terrenget |
Multiplisitet: |
[1..1] |
Type: |
|
Profilparametre i tagged values: |
SOSI_datatype: DATO |
Navn: |
verifiseringsdato |
Definisjon: |
dato når dataene er fastslått å være i samsvar med virkeligheten. Merknad FKB: Brukes for eksempel i de sammenhenger hvor det er foretatt fotogrammetrisk ajourhold, og hvor det ikke er registrert endringer på objektet (det virkelige objektet er i samsvar med dataobjektet) |
Multiplisitet: |
[0..1] |
Type: |
|
Profilparametre i tagged values: |
SOSI_datatype: DATO |
Navn: |
registreringsversjon |
Definisjon: |
angivelse av hvilken produktspesifikasjon som er utgangspunkt for dataene |
Multiplisitet: |
[0..1] |
Type: |
|
Profilparametre i tagged values: |
defaultCodeSpace: https://register.geonorge.no/sosi-kodelister/fkb/generell/5.0/registreringsversjon |
Navn: |
informasjon |
Definisjon: |
generell opplysning. Merknad FKB: Mulighet til å legge inn utfyllende informasjon om objektet. Egenskapen bør bare brukes til å legge inn ekstra informasjon om enkeltobjekter. Egenskapen bør ikke brukes til å systematisk angi ekstrainformasjon om mange/alle objekter i et datasett. |
Multiplisitet: |
[0..1] |
Type: |
Arv og realiseringer
Subtyper: |
«FeatureType» KvalitetOpsjonell |
Realisering av: |
«ApplicationSchema» Generelle typer 5.1/SOSI_Fellesegenskaper og SOSI_Objekt::«FeatureType» SOSI_Fellesegenskaper |
Realisering av: |
«ApplicationSchema» Generelle typer 5.1/SOSI_Fellesegenskaper og SOSI_Objekt::«FeatureType» SOSI_Objekt |
7.2.1.2. «FeatureType» KvalitetPåkrevd (abstrakt)
Definisjon:
Egenskaper
Navn: |
kvalitet |
Definisjon: |
beskrivelse av kvaliteten på stedfestingen Merknad: Denne er identisk med ..KVALITET i tidligere versjoner av SOSI. |
Multiplisitet: |
[1..1] |
Type: |
|
Profilparametre i tagged values: |
SOSI_navn: KVALITET |
Arv og realiseringer
Supertype: |
|
Realisering av: |
«ApplicationSchema» Generelle typer 5.1/SOSI_Fellesegenskaper og SOSI_Objekt::«FeatureType» SOSI_Objekt |
7.2.1.3. «FeatureType» KvalitetOpsjonell (abstrakt)
Definisjon:
Egenskaper
Navn: |
kvalitet |
Definisjon: |
beskrivelse av kvaliteten på stedfestingen Merknad: Denne er identisk med ..KVALITET i tidligere versjoner av SOSI. |
Multiplisitet: |
[0..1] |
Type: |
|
Profilparametre i tagged values: |
SOSI_navn: KVALITET |
Arv og realiseringer
Supertype: |
|
Realisering av: |
«ApplicationSchema» Generelle typer 5.1/SOSI_Fellesegenskaper og SOSI_Objekt::«FeatureType» SOSI_Objekt |
7.2.1.4. «dataType» Identifikasjon
Definisjon: Unik identifikasjon av et objekt i et datasett, forvaltet av den ansvarlige produsent/forvalter, og kan benyttes av eksterne applikasjoner som stabil referanse til objektet.
Merknad 1: Denne objektidentifikasjonen må ikke forveksles med en tematisk objektidentifikasjon, slik som f.eks bygningsnummer.
Merknad 2: Denne unike identifikatoren vil ikke endres i løpet av objektets levetid, og ikke gjenbrukes i andre objekt.
Profilparametre i tagged values
SOSI_navn |
IDENT |
Egenskaper
Navn: |
lokalId |
Definisjon: |
lokal identifikator av et objekt Merknad: Det er dataleverendørens ansvar å sørge for at den lokale identifikatoren er unik innenfor navnerommet. For FKB-data benyttes UUID som lokalId. |
Multiplisitet: |
[1..1] |
Type: |
|
Profilparametre i tagged values: |
SOSI_datatype: T |
Navn: |
navnerom |
Definisjon: |
navnerom som unikt identifiserer datakilden til et objekt, anbefales å være en http-URI Eksempel: http://data.geonorge.no/SentraltStedsnavnsregister/1.0 Merknad : Verdien for navnerom vil eies av den dataprodusent som har ansvar for de unike identifikatorene og må være registrert i data.geonorge.no eller data.norge.no |
Multiplisitet: |
[1..1] |
Type: |
|
Profilparametre i tagged values: |
SOSI_datatype: T |
Navn: |
versjonId |
Definisjon: |
identifikasjon av en spesiell versjon av et geografisk objekt (instans) |
Multiplisitet: |
[0..1] |
Type: |
|
Profilparametre i tagged values: |
SOSI_datatype: T |
Arv og realiseringer
Realisering av: |
«ApplicationSchema» Generelle typer 5.1/SOSI_Fellesegenskaper og SOSI_Objekt::«dataType» Identifikasjon |
7.2.1.5. «dataType» Posisjonskvalitet
Definisjon: beskrivelse av kvaliteten på stedfestingen.
Merknad: Posisjonskvalitet er ikke konform med kvalitetsmodellen i ISO slik den er defineret i ISO19157:2013, men er en videreføring av tidligere brukte kvalitetsegenskaper i SOSI. FKB 5.0 innfører en egen variant av datatypen Posisjonskvalitet der kodeliste målemetode er byttet ut med den mer generelle kodelista Datafangstmetode.
Profilparametre i tagged values
SOSI_navn |
KVALITET |
Egenskaper
Navn: |
datafangstmetode |
Definisjon: |
metode for datafangst. Egenskapen beskriver datafangstmetode for grunnrisskoordinater (x,y), eller for både grunnriss og høyde (x,y,z) dersom det ikke er oppgitt noen verdi for datafangstmetodeHøyde. |
Multiplisitet: |
[1..1] |
Type: |
|
Profilparametre i tagged values: |
defaultCodeSpace: https://register.geonorge.no/sosi-kodelister/fkb/generell/5.0/datafangstmetode |
Navn: |
nøyaktighet |
Definisjon: |
standardavviket til posisjoneringa av objektet oppgitt i cm I de aller fleste sammenhenger benyttes en anslått eller forventet verdi for standardavvik, men dersom man har en beregnet verdi skal denne benyttes. For objekter med punktgeometri benyttes verdi for punktstandardavvik. For objekter med kurvegeometri benyttes standardavviket for tverravviket fra kurva. For objekter med overflate- eller volumgeometri er forståelsen at standardavviket beregnes ut fra (3D) avvikene mellom sann posisjon og nærmeste punkt på overflata. Merknad: Verdien er ment å beskrive nøyaktigheten til objektet sammenlignet med sann verdi. Standardavvik er i utgangspunktet et mål på det tilfeldige avviket og det innebærer at vi forutsetter at det systematiske avviket i liten grad påvirker nøyaktigheten til posisjoneringa. For fotogrammetriske data settes som hovedregel verdien lik kravet til standardavvik ved datafangst. Se standarden Geodatakvalitet for nærmere definisjon av standardavvik og hvordan dette defineres, beregnes og kontrolleres. |
Multiplisitet: |
[0..1] |
Type: |
|
Profilparametre i tagged values: |
SOSI_datatype: H |
Navn: |
synbarhet |
Definisjon: |
beskrivelse av hvor godt objektene framgår i datagrunnlaget for posisjonering (f.eks. flybildene). |
Multiplisitet: |
[0..1] |
Type: |
|
Profilparametre i tagged values: |
defaultCodeSpace: https://register.geonorge.no/sosi-kodelister/fkb/generell/5.0/synbarhet |
Navn: |
datafangstmetodeHøyde |
Definisjon: |
metoden brukt for høyderegistrering av posisjon. Det er bare nødvending å angi en verdi for egenskapen dersom datafangstmetode for høyde avviker fra datafangstmetode for grunnriss. |
Multiplisitet: |
[0..1] |
Type: |
|
Profilparametre i tagged values: |
defaultCodeSpace: https://register.geonorge.no/sosi-kodelister/fkb/generell/5.0/datafangstmetode |
Navn: |
nøyaktighetHøyde |
Definisjon: |
standardavviket til posisjoneringa av objektet oppgitt i cm I de aller fleste sammenhenger benyttes en anslått eller forventet verdi for standardavvik, men dersom man har en beregnet verdi skal denne benyttes. For objekter med punktgeometri benyttes verdi for punktstandardavvik. For objekter med kurvegeometri benyttes standardavviket for tverravviket fra kurva. For objekter med overflate- eller volumgeometri er forståelsen at standardavviket beregnes ut fra (3D) avvikene mellom sann posisjon og nærmeste punkt på overflata. Merknad: Verdien er ment å beskrive nøyaktigheten til objektet sammenlignet med sann verdi. Standardavvik er i utgangspunktet et mål på det tilfeldige avviket og det innebærer at vi forutsetter at det systematiske avviket i liten grad påvirker nøyaktigheten til posisjoneringa. For fotogrammetriske data settes som hovedregel verdien lik kravet til standardavvik ved datafangst. Se standarden Geodatakvalitet for nærmere definisjon av standardavvik og hvordan dette defineres, beregnes og kontrolleres. |
Multiplisitet: |
[0..1] |
Type: |
|
Profilparametre i tagged values: |
SOSI_datatype: H |
Restriksjoner
Navn: |
ugyldige datafangstmetoder for høyde |
Beskrivelse: |
inv: self.datafangstmetodeHøyde <> 'dig' --Datafangstmetode Digitalisert skal ikke brukes på egenskapen datafangstmetodeHøyde |
Arv og realiseringer
Realisering av: |
«ApplicationSchema» Generelle typer 5.1/SOSI_Fellesegenskaper og SOSI_Objekt::«dataType» Posisjonskvalitet |
7.2.1.6. «CodeList» Synbarhet
Definisjon: synbarhet beskriver hvor godt objektene framgår i datagrunnlaget for posisjonering (f.eks. flybildene).
Profilparametre i tagged values
asDictionary |
true |
codeList |
https://register.geonorge.no/sosi-kodelister/fkb/generell/5.0/synbarhet |
SOSI_datatype |
H |
SOSI_lengde |
1 |
SOSI_navn |
SYNBARHET |
7.2.1.7. «CodeList» Datafangstmetode
Definisjon: metode for datafangst.
Datafangstmetoden beskriver hvordan selve vektordataene er posisjonert fra et datagrunnlag (observasjoner med landmålingsutstyr, fotogrammetrisk stereomodell, digital terrengmodell etc.) og ikke prosessen med å innhente det bakenforliggende datagrunnlaget.
Profilparametre i tagged values
asDictionary |
true |
codeList |
https://register.geonorge.no/sosi-kodelister/fkb/generell/5.0/datafangstmetode |
SOSI_datatype |
T |
SOSI_lengde |
3 |
SOSI_navn |
DATAFANGSTMETODE |
7.2.1.8. «CodeList» Registreringsversjon
Definisjon: FKB-verjson som ligger til grunn for registrering. Mest relevant for data som er fotogrammetrisk registrert.
Profilparametre i tagged values
asDictionary |
true |
codeList |
https://register.geonorge.no/sosi-kodelister/fkb/generell/5.0/registreringsversjon |
SOSI_datatype |
T |
SOSI_lengde |
10 |
SOSI_navn |
REGISTRERINGSVERSJON |
7.2.1.9. «CodeList» Høydereferanse
Definisjon: koordinatregistering utført på topp eller bunn av et objekt
Profilparametre i tagged values
asDictionary |
true |
codeList |
https://register.geonorge.no/sosi-kodelister/fkb/generell/5.0/hoydereferanse |
SOSI_datatype |
T |
SOSI_lengde |
6 |
SOSI_navn |
HREF |
7.2.1.10. «CodeList» Medium
Definisjon: objektets beliggenhet i forhold til jordoverflaten
Eksempel: Veg på bro, i tunnel, inne i et bygningsmessig anlegg, etc.
Profilparametre i tagged values
asDictionary |
true |
codeList |
https://register.geonorge.no/sosi-kodelister/fkb/generell/5.0/medium |
SOSI_datatype |
T |
SOSI_lengde |
1 |
SOSI_navn |
MEDIUM |
7.2.2. Pakke: Elementer til bruk i distribusjon
Definisjon: Pakke med elementer som kan benyttes i applikasjonsskjema for distribusjon av FKB-data/FKB-produkter
7.2.2.1. «FeatureType» EkstraegenskaperDistribusjon (abstrakt)
Definisjon: Inneholder ekstraegenskaper som er aktuelle i forbindelse med distribusjon
Egenskaper
Navn: |
kopidata |
Definisjon: |
angivelse av at objektet er hentet fra et kopidatasett og ikke fra originaldatasettet Merknad: Inneholder informasjon om når kopidatasettet ble kopiert fra originaldatasettet og hvem som er originaldataansvarlig |
Multiplisitet: |
[0..1] |
Type: |
|
Profilparametre i tagged values: |
SOSI_navn: KOPIDATA |
Arv og realiseringer
Realisering av: |
«ApplicationSchema» Generelle typer 5.1/SOSI_Fellesegenskaper og SOSI_Objekt::«FeatureType» SOSI_Objekt |
7.2.2.2. «featureType» KantUtsnitt
Definisjon: avgrensning av et utsnitt. KantUtsnitt lagres ikke i forvaltningsbasen men kan benyttes for å lage komplette flateavgrensninger ved klipping av et område ut fra forvaltningsbasen. KantUtsnitt kan finnes i fileksporter.
Egenskaper
Navn: |
grense |
Definisjon: |
forløp som følger overgang mellom ulike fenomener |
Multiplisitet: |
[1..1] |
Type: |
Navn: |
identifikasjon |
Definisjon: |
Unik identifikasjon av objektet |
Multiplisitet: |
[0..1] |
Type: |
Arv og realiseringer
Realisering av: |
«ApplicationSchema» Generelle typer 5.1/Objekttyper med tydelige fellestrekk/Avgrensningslinjer::«FeatureType» KantUtsnitt |
7.2.2.3. «dataType» Kopidata
Definisjon: angivelse av at objektet er hentet fra en kopi av originaldata
Merknad: Kan benyttes dersom man gjør et uttak av en database som ikke inneholder originaldataene.
Profilparametre i tagged values
SOSI_navn |
KOPIDATA |
Egenskaper
Navn: |
områdeId |
Definisjon: |
identifikasjon av område som dataene dekker Merknad: Kan angis med kommunenummer eller fylkesnummer. Disse bør spesifiseres nærmere. |
Multiplisitet: |
[1..1] |
Type: |
|
Profilparametre i tagged values: |
SOSI_datatype: H |
Navn: |
originalDatavert |
Definisjon: |
ansvarlig etat for forvaltning av data |
Multiplisitet: |
[1..1] |
Type: |
|
Profilparametre i tagged values: |
SOSI_datatype: T |
Navn: |
kopidato |
Definisjon: |
dato når objektet ble kopiert fra originaldatasettet Merknad: Er en del av egenskapen Kopidata. Brukes i de tilfeller hvor en kopidatabase brukes til distribusjon. Å kopiere et datasett til en kopidatabase skal ikke føre til at Oppdateringsdato blir endret. Eventuell redigering av data i et kopidatasett medfører ny Oppdateringsdato, Datafangstdato og/eller Verifiseringsdato. |
Multiplisitet: |
[1..1] |
Type: |
|
Profilparametre i tagged values: |
SOSI_datatype: DATOTID |
Arv og realiseringer
Realisering av: |
«ApplicationSchema» Generelle typer 5.1/SOSI_Fellesegenskaper og SOSI_Objekt::«dataType» Kopidata |
8. Kvalitet
8.1. Kvalitet på FKB-data
FKB data oppdateres gjennom forskjellige prosesser og det er et overordnet prinsipp at fullstendighet prioriteres framfor homogen stedfestingsnøyaktighet. FKB-data er en blanding av data med ulike datakilder og kvalitet. Et resultat av dette er at det er vanskelig å garantere stedfestingsnøyaktigheten til FKB-data innenfor et område. For å ha full kontroll på kvaliteten på FKB-dataene i en leveranse må man derfor se på kvalitetskodingen (metadata) på det enkelte objekt. Kravene til kvalitet på FKB settes ved datafangst.
Fotogrammetri er fortsatt den dominerende datakilden. For de fleste FKB-datasett har over 99% av kartobjektene fotogrammetri som datafangsmetode. Ved fotogrammetrisk datafangst settes det klare krav til kvaliteten og det utføres kontroll. Ambisjonen er at FKB-dataene skal ha en så god og homogen kvalitet som mulig og det jobbes for å sette tilsvarende krav til dataene også ved andre typer datafangst.
8.2. Kvalitetselementer som benyttes for å sette krav til FKB-data
I dette avsnittet er det angitt hvilke kvalitetselementer som skal benyttes i spesifikasjoner for datafangst av FKB-data. Kvalitetselementene er hentet fra Geodatakvalitet [G] og det henvises til denne standarden for nærmere beskrivelse av de ulike kvalitetselementene og kvalitetsmålene, og for prinsipper for kontroll av kravene i en leveranse.
I enkelte sammenhenger kan det også være behov for å sette krav til FKB-dataene som ikke lar seg beskrive av kvalitetsmålene som er definert i Geodatakvalitet. I slike sammenhenger må det i såfall utarbeides egne kvalitetsmål (dvs. beskrives detaljert hva kravet går ut på og hvordan det skal kontrolleres). Dette kan være spesifikke krav til topologisk konsistens eller lignende.
I FKB er det kun kvalitetselementet stedfestingsnøyaktighet med tilhørende datafangstmetode, samt datering som obligatorisk skal ligge i selve dataene. Informasjon om øvrige kvalitetselementer vil normalt finnes i kontrollrapporter for det enkelte kartleggingsprosjekt eller som metadatainformasjon.
Kvalitetselement | Kvalitetsmål | Referanse |
---|---|---|
Grunnrissnøyaktighet |
Grove feil (%) |
Geodatakvalitet:2014/301/1 |
Grunnrissnøyaktighet |
Systematiske feil (m) |
Geodatakvalitet:2014/303/1 |
Grunnrissnøyaktighet |
Standardavvik (m) |
Geodatakvalitet:2014/304/1 |
høydenøyaktighet |
Grove feil (%) |
Geodatakvalitet:2014/301/1 |
høydenøyaktighet |
Systematiske feil (m) |
Geodatakvalitet:2014/302/1 |
høydenøyaktighet |
Standardavvik (m) |
Geodatakvalitet:2014/304/1 |
Ved kontroll av stedfestingsnøyaktighet må man alltid kontrollere både standardavvik, systematiske avvik og andel grove feil mot en fasit [G].
Kvalitetselement | Kvalitetsmål | Referanse | Kommentar |
---|---|---|---|
Domenekonsistens |
Antall enheter som ikke er i samsvar med domenet |
NS-EN ISO19157:2013/016/1 |
Objekttyper, egenskaper og egenskapsverdier skal være i tråd med datamodellen. Kontrolleres f.eks. ved GML-validering eller SOSI-kontroll |
Konseptuell konsistens |
Antall enheter der regler i konseptuelt skjema ikke er oppfylt |
NS-EN ISO19157:2013/010/1 |
Må spesifiseres nærmere hvilke krav i det konseptuelle skjemaet som skal oppfylles dersom kvalitetsmålet skal benyttes. |
Topologisk konsistens |
Antall ulovlige løse ender |
Geodatakvalitet:2014/201/1 |
Må spesifiseres nærmere hva som regnes som en ulovlig løs ende dersom kvalitetsmålet skal benyttes |
Topologisk konsistens |
Antall feil i lenkekryssing |
Geodatakvalitet:2014/202/1 |
Må spesifiseres nærmere hvilke typer lenkekryssinger som regnes som feil dersom kvalitetsmålet skal benyttes |
Topologisk konsistens |
Antall ulovlige egenoverlappinger |
NS-EN ISO19157:2013/027/1 |
Kvalitetsmål som generelt kan settes til objekter med kurvegeometri |
Topologisk konsistens |
Antall ulovlige egenkryssinger |
NS-EN ISO19157:2013/026/1 |
Kvalitetsmål som kan settes til objekter med kurvegeometri som inngår i flateavgrensninger |
Topologisk konsistens |
Antall ulovlige småpolygoner |
NS-EN ISO19157:2013/025/1 |
Må spesifiseres nærmere hvilke typer småpolygoner som regnes som feil dersom kvalitetsmålet skal benyttes |
Topologisk konsistens |
Prosentandel feil på fulldekkende flater |
Geodatakvalitet:2014/204/1 |
Kvalitetsmål som er aktuelt på objekttyper som skal utgjøre en heldekkende flate i et område |
For alle kvalitetsmål som måler «antall avvik» på logisk konsistens er det naturlig at kravet settes til 0 dersom kvalitetsmålet anvendes.
Kvalitetselement | Kvalitetsmål | Referanse |
---|---|---|
Klassifikasjonsriktighet |
Prosentandel feil klassifiserte egenskaper |
Geodatakvalitet:2014/508/1 |
Kvalitetselement | Kvalitetsmål | Referanse |
---|---|---|
Manglende objekter |
Prosentandel manglende objekter |
Geodatakvalitet:2014/102/1 |
Overskytende objekter |
Prosentandel overskytende objekter |
Geodatakvalitet:2014/101/1 |
Når man setter krav til datakvalitet i fotogrammetrisk registreringsinstruks og andre spesifikasjoner for datafangst av FKB-data skal det alltid settes krav til stedfestingskvalitet, egenskapskvalitet og fullstendighet ved hjelp av alle kvalitetsmålene som er definert i tabellene over. For logisk konsistens er flere av kvalitetsmålene av en slik natur at det må spesifiseres nærmere hvilke typer situasjoner som regnes som et avvik. Her må det gjøres et valg av hvilke kvalitetsmål som skal anvendes og ev. en nærmere spesifisering av hva som ligger i kravene i den enkelt spesifikasjon.
8.3. Krav til stedfestingsnøyaktighet - inndeling i klasser
For å angi krav til stedfestingsnøyaktighet er det definert fire klasser som objekttypene er inndelt i. Inndelingen i klasser bygger på hvor skarpt objekttypen er definert i terrenget. Denne inndelingen i nøyaktighetsklasser benyttes gjennomgående for alle datasett som inngår i fotogrammetrisk FKB og kan også anvendes som utgangspunkt for å sette krav til innsamling av FKB-data med andre metoder. For å få en oversikt over hvilke krav som gjelder for ulike objekttyper henvises det til spesifikasjonen av det enkelte FKB-datasett.
FKB-Standard |
Nøyaktighetsklasser |
||||
Klasse 1 Svært veldefinerte detaljer (cm) |
Klasse 2 Veldefinerte detaljer (cm) |
Klasse 3 Uskarpe detaljer (cm) |
Klasse 4 Diffuse detaljer (cm) |
||
FKB-A |
Grunnriss |
3 / 10 |
5 / 15 |
10 / 35 |
15 / 55 |
Høyde |
3 / 10 |
5 / 15 |
8 / 25 |
12 / 40 |
|
FKB-B |
Grunnriss |
5 / 15 |
6 / 20 |
10 / 35 |
15 / 55 |
Høyde |
5 / 15 |
6 / 20 |
10 / 35 |
15 / 50 |
|
FKB-C/D |
Grunnriss |
15 / 48 |
15 / 55 |
20 / 70 |
30 / 100 |
Høyde |
15 / 48 |
20 / 70 |
25 / 90 |
40 / 150 |
I tidligere versjoner av FKB har det ikke blitt definert egne krav til systematiske avvik. Det har i stedet blitt beskrevet at «systematiske avvik ikke skal trekkes fra ved beregning av standardavvik» noe som avviker fra definisjonen av standardavvik. Tidligere bruk av «standardavvik» i FKB har lignet mer på begrepet RMS etter definisjon i Geodatakvalitet.
For å kunne følge standarden Geodatakvalitet fullt ut ved kontroll av data innføres fra FKB 5.1 eksplisitte krav til både systematiske avvik og standardavvik (se tabell 5). Kravene til systematiske avvik er satt slik at de maksimalt er 1/3 av krav til standardavvik. Kravene til systematisk avvik er basert på erfaringstall, samt at det sikrer at det systematiske avviket bare vil utgjøre en liten andel av det totale avviket mellom sann posisjon og målt posisjon. Kravet til standardavvik brukes derfor alene som et mål på dataenes nøyaktighet i metadataene.
Krav til grove feil
Grove feil regnes som avvik større enn 3 ganger krav til standardavviket angitt i tabellen over. Kravet vil vanligvis være maksimalt 1 % grove feil, men kan variere for ulike objekttyper og angis i den enkelte FKB produktspesifikasjon.
8.4. Avvik funnet ved kontroll av FKB-data
Produktspesifikasjon AvvikKartdata 1.0 spesifiserer hvordan avvik på kartdata skal utveksles. I forbindelse med utveksling av avvik knyttet til FKB-data i FKB-Kartleggingsprosjekter eller andre sammenhenger skal denne produktspesifikasjonen legges til grunn.
Vedlegg A: Utvekslingsformater for FKB-data
FKB 5.1 er laget spesielt med tanke på utveksling på GML-format [SOSI-GML] og SOSI-format [SOSI-FORMAT]. Alle FKB 5.1-data kan konverteres fram og tilbake mellom SOSI-format og GML-format uten at man mister informasjon.
I tillegg er ESRI fgdb et populært format for filbasert distribusjon gjennom geonorge og JSON [JSON] er et populært format ved jobbing mot Sentral FKB med NGIS-OpenAPI [NGIS]. For ESRI fgdb og JSON-formatene finnes det ikke standarder som beskriver krav til utvekslingsformatet i detalj.
A.1. Leveranseformater ved distribusjon fra Geonorge
Format | Inndeling | Koordinatsystem | Tegnsett | Språk |
---|---|---|---|---|
GML 3.2.1 |
Kommunevise filer |
Euref89 UTM33 + lokal UTM-sone |
UTF-8 |
nor |
SOSI-format 5.0 |
Kommunevise filer |
Euref89 UTM33 + lokal UTM-sone |
UTF-8 |
nor |
ESRI fgdb |
Kommunevise filer |
Euref89 UTM33 + lokal UTM-sone |
UTF-8 |
nor |
ESRI fgdb |
Landsdekkende + fylkesvise filer |
Euref89 UTM33 |
UTF-8 |
nor |
A.2. Formater i NGIS-OpenAPI
NGIS-OpenAPI er det nye og fleksible API-et for oppdatering av (blant annet) FKB-data [NGIS].
I NGIS-OpenAPI benyttes enten GML-format eller JSON-format for dataoverføring. GML-formatet er på samme måte som GML-filer ved distribusjon gitt av GML-Schema for produktspesifikasjonene og pakkes inn i WFS-T transaksjoner [WFS]. Dette er samme type dataformat som også brukes i Geosynkronisering-API.
Alternativt kan JSON-format benyttes i NGIS-OpenAPI. Dette formatet er basert på GeoJSON RFC 7946, august 2016 med utvidelser. Et programbibliotek som kan tolke GeoJSON vil også kunne lese dataene som utveksles med NGIS-OpenAPI, men vil ikke uten videre kunne tolke innholdet i utvidelsene. Utvidelsene brukes til f.eks. å utveksle informasjon om assosiasjoner, flatereferanser ved delt geometri og action ved oppdateringer (insert/replace/erase). Se dokumentasjon av NGIS-OpenAPI for eksempler på filformat ved bruk av API-et.
Vedlegg B: Romlige referansesystem
FKB-data er detaljerte data med høy presisjon. Dette betyr at man må være bevisst på ev. feil som kan innføres ved transformasjon av dataene mellom forskjellige romlige referansesystemer. I forvaltningen av FKB-data gjøres vanligvis oppdateringen direkte i den aktuelle kommunens koordinatsystem slik at man unngår transformasjon av data. Kommuner i Finnmark fylke har EUREF89 UTM35 som lokal sone. Kommuner i Nordland og Troms har EUREF89 UTM33 som lokal sone, mens kommuner fra Trøndelag og sørover bruker EUREF89 UTM32 som lokal sone.
Dersom det skal tillates oppdatering med transformasjon inn i FKB-dataene må det benyttes en transformasjon som gir presisjon bedre enn oppløsningen i FKB-dataene (i praksis bedre en ca 5 mm).
Referansesystem | EPSG-kode (GML/JSON-format) | SOSI-kode (SOSI-format) |
---|---|---|
25832 |
Koordsys 22, Vert-datum ikke angitt |
|
25833 |
Koordsys 23, Vert-datum ikke angitt |
|
25835 |
Koordsys 25, Vert-datum ikke angitt |
|
5972 |
Koordsys 22, Vert-datum NN2000 |
|
5973 |
Koordsys 23, Vert-datum NN2000 |
|
5975 |
Koordsys 25, Vert-datum NN2000 |
Ved distribusjon kan dataene transformeres til en rekke andre referansesystemer ved help av standard transformasjonsbiblioteker.
Vedlegg C: Assosiasjoner og flategeometri på SOSI- og GML-format
Generelt gjelder SOSI del 1 Realisering av GML-format 5.0 [SOSI-GML] og Realisering av SOSI-format 5.0 [SOSI-FORMAT] ved utveksling av FKB-data. I FKB 5.0 ble Assosiasjoner og endringer i håndtering av Flategeometri innført. Dette vedlegget inneholder detaljer om hvordan dette skal utveksles på SOSI- og GML-format inkludert korte eksempler.
C.1. Utveksling av assosiasjoner
C.1.1. SOSI-format
I SOSI-formatet utveksles assosiasjoner med referanser til SOSI-gruppenummer (altså kun unikt innenfor SOSI-fila).
.KURVE 1:
..OBJTYPE Bardun
..IDENT
...LOKALID "5e1d42bb-fd1c-4a58-92dc-aa0b3fadf57d"
...NAVNEROM "http://data.geonorge.no/SFKB/50/FKB-Ledning/so"
...VERSJONID "2021-09-24 11:51:54.015000"
..OPPDATERINGSDATO 20210929133801
..DATAFANGSTDATO 20210924
..VERIFISERINGSDATO 20210924
..REGISTRERINGSVERSJON 2022-01-01
..INFORMASJON "Dette er fiktive eksempeldata"
..HREF TOP
..MEDIUM T
..KVALITET
...DATAFANGSTMETODE fot
...NØYAKTIGHET 120
...SYNBARHET 0
...DATAFANGSTMETODEHØYDE fot
...H-NØYAKTIGHET 200
..DRIFTSMERKING "ABCD1234"
..EIERORGNR "234567891"
..EKSTERNPEKER https://enangitturl/geografiskobjekt/5e1d42bb-fd1c-4a58-92dc-aa0b3fadf57d
..LEDNINGSNETTVERKSTYPE ekom
..NØH
7034142346 567181215 43670
7034142346 567189494 65130
.PUNKT 2:
..OBJTYPE Mast
..IDENT
...LOKALID "81ffc802-3e9f-492b-95b6-bb15b645a7e8"
...NAVNEROM "http://data.geonorge.no/SFKB/50/FKB-Ledning/so"
...VERSJONID "2021-09-24 11:51:54.015000"
..OPPDATERINGSDATO 20210929133801
..DATAFANGSTDATO 20210924
..VERIFISERINGSDATO 20210924
..REGISTRERINGSVERSJON 2022-01-01
..INFORMASJON "Dette er fiktive eksempeldata"
..HREF TOP
..MEDIUM T
..KVALITET
...DATAFANGSTMETODE fot
...NØYAKTIGHET 30
...SYNBARHET 0
...DATAFANGSTMETODEHØYDE fot
...H-NØYAKTIGHET 110
..DRIFTSMERKING "ABCD1234"
..EIERORGNR "234567891"
..EKSTERNPEKER https://enangitturl/geografiskobjekt/81ffc802-3e9f-492b-95b6-bb15b645a7e8
..LEDNINGSNETTVERKSTYPE lavspentnett
..ANTALL_LASERPUNKT 55
..BELYSNING JA
..MASTEKONSTRUKSJON enkelStolpe
..LINJEBREDDE 0.23
..VERTIKALAVSTAND 8.23
..BARDUN :1
..NØH
7034127981 567190174 126900
C.1.2. GML-format
I GML-formatet utveksles assosiasjoner med mekanismen xlink:href på objektet det pekes fra til GML-Id på objektet det pekes til. GML-Id skal i FKB utformes etter konvensjonen «objekttypenavn_lokalid» slik at denne er unik/meningsfull også på utsiden av GML-fila.
<gml:featureMembers>
<gml:featureMember>
<app:Bardun gml:id="Bardun_5e1d42bb-fd1c-4a58-92dc-aa0b3fadf57d">
<app:identifikasjon>
<app:Identifikasjon>
<app:lokalId>5e1d42bb-fd1c-4a58-92dc-aa0b3fadf57d</app:lokalId>
<app:navnerom>http://data.geonorge.no/SFKB/50/FKB-Ledning/so</app:navnerom>
</app:Identifikasjon>
</app:identifikasjon>
<app:oppdateringsdato>2021-09-24T10:41:12</app:oppdateringsdato>
<app:datafangstdato>2021-09-24</app:datafangstdato>
<app:verifiseringsdato>2021-09-24</app:verifiseringsdato>
<app:registreringsversjon>2022-01-01</app:registreringsversjon>
<app:informasjon>Dette er fiktive eksempeldata</app:informasjon>
<app:høydereferanse>TOP</app:høydereferanse>
<app:medium>T</app:medium>
<app:kvalitet>
<app:Posisjonskvalitet>
<app:datafangstmetode>fot</app:datafangstmetode>
<app:nøyaktighet>120</app:nøyaktighet>
<app:synbarhet>0</app:synbarhet>
<app:datafangstmetodeHøyde>fot</app:datafangstmetodeHøyde>
<app:nøyaktighetHøyde>200</app:nøyaktighetHøyde>
</app:Posisjonskvalitet>
</app:kvalitet>
<app:driftsmerking>ABCD1234</app:driftsmerking>
<app:eierOrgNr>234567891</app:eierOrgNr>
<app:eksternPeker>https://enangitturl/geografiskobjekt/5e1d42bb-fd1c-4a58-92dc-aa0b3fadf57d</app:eksternPeker>
<app:hovedbruk>ekom</app:hovedbruk>
<app:senterlinje>
<gml:Curve gml:id="geom_2a02c15b-0512-43e3-8ac8-55836ab84bba" srsName="urn:ogc:def:crs:EPSG::5972" srsDimension="3">
<gml:segments>
<gml:LineStringSegment>
<gml:posList>567181.346 7034142.215 43.670 567189.494 7034142.346 65.130</gml:posList>
</gml:LineStringSegment>
</gml:segments>
</gml:Curve>
</app:senterlinje>
</app:Bardun>
</gml:featureMember>
<gml:featureMember>
<app:Mast gml:id="Mast_81ffc802-3e9f-492b-95b6-bb15b645a7e8">
<app:identifikasjon>
<app:Identifikasjon>
<app:lokalId>81ffc802-3e9f-492b-95b6-bb15b645a7e8</app:lokalId>
<app:navnerom>http://data.geonorge.no/SFKB/50/FKB-Ledning/so</app:navnerom>
</app:Identifikasjon>
</app:identifikasjon>
<app:oppdateringsdato>2021-09-24T10:41:16.56</app:oppdateringsdato>
<app:datafangstdato>2021-09-24</app:datafangstdato>
<app:verifiseringsdato>2021-09-24</app:verifiseringsdato>
<app:registreringsversjon>2022-01-01</app:registreringsversjon>
<app:informasjon>Dette er fiktive eksempeldata</app:informasjon>
<app:høydereferanse>TOP</app:høydereferanse>
<app:medium>T</app:medium>
<app:kvalitet>
<app:Posisjonskvalitet>
<app:datafangstmetode>fot</app:datafangstmetode>
<app:nøyaktighet>30</app:nøyaktighet>
<app:synbarhet>0</app:synbarhet>
<app:datafangstmetodeHøyde>fot</app:datafangstmetodeHøyde>
<app:nøyaktighetHøyde>110</app:nøyaktighetHøyde>
</app:Posisjonskvalitet>
</app:kvalitet>
<app:driftsmerking>ABCD1234</app:driftsmerking>
<app:eierOrgNr>234567891</app:eierOrgNr>
<app:eksternPeker>https://enangitturl/geografiskobjekt/81ffc802-3e9f-492b-95b6-bb15b645a7e8</app:eksternPeker>
<app:hovedbruk>lavspentnett</app:hovedbruk>
<app:posisjon>
<gml:Point gml:id="geom_acf77bef-c6de-4fbf-a5c0-2b5f0035f46j" srsName="urn:ogc:def:crs:EPSG::5972" srsDimension="3">
<gml:pos>567190.174 7034127.981 126.900</gml:pos>
</gml:Point>
</app:posisjon>
<app:antallLaserPunkt>55</app:antallLaserPunkt>
<app:belysning>true</app:belysning>
<app:konstruksjon>enkelStolpe</app:konstruksjon>
<app:linjebredde>0.23</app:linjebredde>
<app:vertikalAvstand>8.23</app:vertikalAvstand>
<app:bardun xlink:href="#Bardun_5e1d42bb-fd1c-4a58-92dc-aa0b3fadf57d" />
</app:Mast>
</gml:featureMember>
</gml:featureMembers>
C.2. Utveksling av flategeometri
C.2.1. SOSI-format
SOSI-formatet er bygget opp med referanser til avgrensningsobjektene i stedet for at flateobjektene inneholder selve geometrien. Flater med delt geometri ("Type 2") kan derfor utveksles som tradisjonelle SOSI .FLATE-objekter med flatereferanser (.REF). Om man ønsker å utveksle flater med heleid geometri ("Type 1") i SOSI så skal man etablere et "hjelpeobjekt" i form av en .KURVE-gruppe med objekttype Flateavgrensning (som ikke har noen identifikasjon/lokalid) som inneholder hele flateavgrensningen og refereres fra .FLATE-objektet. Dersom "Type 1"-flaten inneholder øyer/hull må det etableres egne Flateavgrensning SOSI-grupper også for disse som referes som hull etter vanlige regler for SOSI-formatet.
.KURVE 1:
..OBJTYPE Flatevgrensning
..NØH
6661981480 569544030 89200
6662009490 569606410 91200
6661998970 569625840 90800
6662001850 569629640 91000
6662054940 569635020 91500
6662067850 569576330 90500
6662054490 569566500 90500
6661981480 569544030 89200
.FLATE 2:
..OBJTYPE Anleggsområde
..IDENT
...LOKALID 58c892c4-f615-4317-935f-038765687265
...NAVNEROM "http://data.geonorge.no/SOSI/FKB-Arealbruk"
..OPPDATERINGSDATO "2021-08-26T21:08:00Z"
..DATAFANGSTDATO "2021-08-26"
..KVALITET
...DATAFANGSTMETODE "fot"
...NØYAKTIGHET "42"
...SYNBARHET "1"
...DATAFANGSTMETODEHØYDE "fot"
...H-NØYAKTIGHET "42"
..REF :1
..NØ
6662024665 568494636
.FLATE 1:
..OBJTYPE Bygning
..IDENT
...LOKALID 5e1d42bb-fd1c-4a58-92dc-aa0b3fadf57d
...NAVNEROM "http://data.geonorge.no/SFKB/FKB-Bygning/so"
..REF :2 :-3
..NØH
56844403 666198148 8920
.KURVE 2:
..OBJTYPE Bygningsavgrensning
..IDENT
...LOKALID 81ffc802-3e9f-492b-95b6-bb15b645a7e8
...NAVNEROM "http://data.geonorge.no/SFKB/FKB-Bygning/so"
..NØH
56852584 666199897 9080
56850641 666200949 9120
56844403 666198148 8920
.KURVE 3:
..OBJTYPE Bygningsavgrensning
..IDENT
...LOKALID 32face7c-c0d8-4264-ac2d-1e47977cc976
...NAVNEROM "http://data.geonorge.no/SFKB/FKB-Bygning/so"
..NØH
56852584 666199897 9080
56852964 666200185 9100
56853502 666205494 9150
56847633 666206785 9050
56846650 666205449 9050
56844403 666198148 8920
C.2.2. GML-format
En "Type 1" flate vil i GML være rett fram å utveksle som en gml:Surface med heleid geometri. Om man skal utveksle en flate av "Type 2" i GML vil man også sende med flate-objektets komplette egengeometri som gml:Surface. I tillegg er det definert regler for hvordan referansene til de assosierte avgrensningsobjektene skal utveksles:
-
Referanse fra flateobjekt til avgrensningsobjekt legges som en xlink:href på flateobjektet som peker på GML-Id for avgrensningsobjektet. Dette er i tråd med krav til - og erfaringer med - hvordan assosiasjoner utveksles på GML-formatet.
-
GML-Id utformes etter konvensjonen «objekttypenavn_lokalid» slik at denne er unik/meningsfull også på utsiden av GML-fila.
-
Informasjon om rekkefølge og retning på de assosierte avgrensningsobjektene legges inn ved bruk av taggen xlink:title. I tilfellene der dette er interessant forutsettes det at xlink:title formateres med 4 kolonner:
-
Kolonne 1: sekvensnummer til flate – 0 er første flate (høyere tall ved multisurface/multipolygon)
-
Kolonne 2: sekvensnummer til ring – ytre begrensing = 0, første hull = 1, osv.
-
Kolonne 3: sekvensnummer til kurve - 0 er første
-
Kolonne 4: retning + eller – (om avgrensningsobjektet skal nøstes med eller mot koordinatretningen)
-
<gml:featureMembers>
<gml:featureMember>
<app:Anleggsområde gml:id="Anleggsområde_58c892c4-f615-4317-935f-038765687265">
<app:identifikasjon>
<app:Identifikasjon>
<app:lokalId>58c892c4-f615-4317-935f-038765687265</app:lokalId>
<app:navnerom>http://data.geonorge.no/SOSI/FKB-Arealbruk</app:navnerom>
</app:Identifikasjon>
</app:identifikasjon>
<app:oppdateringsdato>2021-08-26T21:08:00</app:oppdateringsdato>
<app:datafangstdato>2021-08-26</app:datafangstdato>
<app:kvalitet>
<app:Posisjonskvalitet>
<app:datafangstmetode>fot</app:datafangstmetode>
<app:nøyaktighet>42</app:nøyaktighet>
<app:synbarhet>2</app:synbarhet>
<app:datafangstmetodeHøyde>fot</app:datafangstmetodeHøyde>
<app:nøyaktighetHøyde>42</app:nøyaktighetHøyde>
</app:Posisjonskvalitet>
</app:kvalitet>
<app:område>
<gml:Polygon gml:id="1" srsName="urn:ogc:def:crs:EPSG::5972" srsDimension="3">
<gml:exterior>
<gml:LinearRing>
<gml:posList>568444.03 6661981.48 89.2 568506.41 6662009.49 91.2 568525.84 6661998.97 90.8 568529.64 6662001.85 91 568535.02 6662054.94 91.5 568476.33 6662067.85 90.5 568466.5 6662054.49 90.5 568444.03 6661981.48 89.2</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</app:område>
</app:Anleggsområde>
</gml:featureMember>
</gml:featureMembers>
<gml:featureMembers>
<gml:featureMember>
<app:Bygning gml:id="Bygning_5e1d42bb-fd1c-4a58-92dc-aa0b3fadf57d">
<app:identifikasjon>
<app:Identifikasjon>
<app:lokalId>5e1d42bb-fd1c-4a58-92dc-aa0b3fadf57d</app:lokalId>
<app:navnerom>http://data.geonorge.no/SOSI/FKB-Bygning</app:navnerom>
</app:Identifikasjon>
</app:identifikasjon>
<app:område>
<gml:Polygon gml:id="geom_1" srsName="urn:ogc:def:crs:EPSG::5972" srsDimension="3">
<gml:exterior>
<gml:LinearRing>
<gml:posList>568444.03 6661981.48 89.20 568506.41 6662009.49 91.20 568525.84 6661998.97 90.80 568529.64 6662001.85 91.00 568535.02 6662054.94 91.50 568476.33 6662067.85 90.50 568466.50 6662054.49 90.50 568444.03 6661981.48 89.20</gml:posList>
</gml:LinearRing>
</gml:exterior>
</gml:Polygon>
</app:område>
<app:sentralpunkt>
<gml:Point gml:id="geom_2" srsName="urn:ogc:def:crs:EPSG::5972" srsDimension="3">
<gml:pos>568497.68 6662024.15 90.67</gml:pos>
</gml:Point>
</app:sentralpunkt>
<app:avgrensning xlink:title="0 0 0 -" xlink:href="#Bygningsavgrensning_81ffc802-3e9f-492b-95b6-bb15b645a7e8"/>
<app:avgrensning xlink:title="0 0 1 +" xlink:href="#Bygningsavgrensning_32face7c-c0d8-4264-ac2d-1e47977cc976"/>
</app:Bygning>
</gml:featureMember>
<gml:featureMember>
<app:Bygningsavgrensning gml:id="Bygningsavgrensning_81ffc802-3e9f-492b-95b6-bb15b645a7e8">
<app:identifikasjon>
<app:Identifikasjon>
<app:lokalId>81ffc802-3e9f-492b-95b6-bb15b645a7e8</app:lokalId>
<app:navnerom>http://data.geonorge.no/SOSI/FKB-Bygning</app:navnerom>
</app:Identifikasjon>
</app:identifikasjon>
<app:grense>
<gml:Curve gml:id="geom_3" srsName="urn:ogc:def:crs:EPSG::5972" srsDimension="3">
<gml:segments>
<gml:LineStringSegment>
<gml:posList>568525.84 6661998.97 90.80 568506.41 6662009.49 91.20 568444.03 6661981.48 89.20</gml:posList>
</gml:LineStringSegment>
</gml:segments>
</gml:Curve>
</app:grense>
</app:Bygningsavgrensning>
</gml:featureMember>
<gml:featureMember>
<app:Bygningsavgrensning gml:id="Bygningsavgrensning_32face7c-c0d8-4264-ac2d-1e47977cc976">
<app:identifikasjon>
<app:Identifikasjon>
<app:lokalId>32face7c-c0d8-4264-ac2d-1e47977cc976</app:lokalId>
<app:navnerom>http://data.geonorge.no/SOSI/FKB-Bygning</app:navnerom>
</app:Identifikasjon>
</app:identifikasjon>
<app:grense>
<gml:Curve gml:id="geom_4" srsName="urn:ogc:def:crs:EPSG::5972" srsDimension="3">
<gml:segments>
<gml:LineStringSegment>
<gml:posList>568525.84 6661998.97 90.80 568529.64 6662001.85 91.00 568535.02 6662054.94 91.50 568476.33 6662067.85 90.50 568466.50 6662054.49 90.50 568444.03 6661981.48 89.20</gml:posList>
</gml:LineStringSegment>
</gml:segments>
</gml:Curve>
</app:grense>
</app:Bygningsavgrensning>
</gml:featureMember>
</gml:featureMembers>
Vedlegg D: Generelle retningslinjer for fotogrammetrisk registrering av FKB (Normativt)
D.1. Fotogrammetrisk nykonstruksjon
Ved fotogrammetrisk nykonstruksjon skal alle objektene som er spesifisert i registreringsinstruksen og som er synlige i flybildene registreres.
D.1.1. Registrering av nye kartobjekter
Hovedregelen er at påkrevde objekttyper registreres, mens opsjonelle objekttyper ikke registreres.
Unntak fra hovedregelen kan avtales i teknisk spesifikasjon for kartleggingsprosjektet.
D.1.2. Registrering av egenskaper på nye kartobjekter
Hovedregelen er at obligatoriske egenskaper registreres, mens opsjonelle egenskaper ikke registreres ved fotogrammetrisk datafangst.
Egenskaper som skal registreres/klassifiseres ved hjelp av fotogrammetri er beskrevet spesielt i registreringsinstruksen. Opsjonelle egenskaper som ikke er spesielt nevnt i registreringsinstruksen skal ikke registreres med mindre annet er spesielt angitt.
Følgende egenskaper håndteres spesielt:
-
Egenskapen Identifikasjon skal ikke legges inn på objektene
-
Egenskapen Oppdateringsdato skal ikke legges inn på objektene
-
Alle objekter skal ha egenskapene Nøyaktighet og NøyaktighetHøyde som del av datatypen Posisjonskvalitet
-
Alle objekter skal ha egenskapen Registreringsversjon
Unntak fra hovedreglene kan spesifiseres under den enkelte objekttype/egenskap i den enkelte registreringsinstruks eller i teknisk spesifikasjon for kartleggleggingsprosjektet.
Assosiasjoner håndteres ved fotogrammetrisk registrering av FKB-data på samme måte som opsjonelle egenskaper. Dvs. at det ikke skal etableres assosiasjoner i dataene dersom det ikke er spesielt beskrivet i den enkelte registreringsinstruks eller avtalt i kartleggingsprosjektet.
D.1.2.1. Kvalitet og datafangstdato
Alle objekter som registreres fotogrammetrisk skal merkes med kvalitet og datafangstdato.
I følge definisjonen av Datafangstdato skal dette være datoen for når flybildene som ligger til grunn for kartkonstruksjonen ble tatt (flyfotodato). I en del kartleggingsprosjekter kan imidlertid bildene være tatt på ulike datoer og det kan da være ønskelig at alle data i prosjektet likevel får samme dato. Dersom man ønsker å gjøre det på denne måten skal dette avklares i det enkelte prosjekt.
I FKB 5.1 er kun datafangstdato satt som påkrevd egenskap i datatypen «dataType» Posisjonskvalitet. Ved fotogrammetrisk regisrering skal imidlertid alltid også nøyaktighet og synbarhet registreres. Alle objekter som registreres fotogrammetrisk registreres med datafangstmetode fot.
I SOSI-formatet skal ingen egenskaper kompaktifiseres i FKB 5.1. Dette gjelder også posisjonskvalitet (dvs. at datafangstmetode, nøyaktighet etc. angis som egenskaper på 3-prikksnivå under ..KVALITET).
D.1.2.2. Obligatoriske egenskaper med kodelister
En del egenskaper med kodelister er angitt som påkrevde. Dette krever at det legges på en verdi ved fotogrammetrisk registrering. For slike egenskaper skal det være definert en "standardverdi" som benyttes i de tilfellene det ikke er angitt noe annet. Konkrete regler for hvordan dette skal registreres for de enkelte objekttyper/egenskaper skal være angitt i registreringsinstruksen. Egenskapene Medium og Høydereferanse (HREF) er benyttet på mange objekter i flere FKB-datasett og for disse gjelder følgende generelle regler dersom ikke annet er spesielt angitt:
Kodeverdi | Forklaring |
---|---|
T (på terrenget) |
Standardverdi. Benyttes for alle objekter der det ikke er grunn til å benytte en annen verdi |
U (under terrenget) |
Objekter under bakken er generelt lite aktuelt for fotogrammetrisk registrering, men det kan likevel være aktuelt å benytte denne verdien for objekter (delvis) under bruer/bygninger/kulverter etc. der det ikke er direkte innsyn med fotogrammetri, men krav til gjennomgående registrering av objektet. |
B (på bygning) |
Benyttes for objekter på toppen av (på taket av) bygninger og ev. andre konstruksjoner. |
L (i lufta) |
Benyttes for generelt for objekter befinner seg lufta. Dette kan være objekter i en stolpe eller på en bru. Bruk er presisert for en del objekttyper. |
Enkelte objekttyper kan ha spesielle beskrivelser av bruk av andre koder for Medium. F.eks. er det presisert at en Veranda på et tak (takterrasse) registreres med Medium B, mens en Veranda som henger på en vegg (balkong) registreres med Medium L.
Medium brukes i stor grad for å styre tegneregler for FKB-dataene. Altså slik at objekter med Medium U typisk ikke tegnes ut (ev. stiples), mens objekter med Medium L tegnes over/oppå andre objekter.
Kodeverdi | Forklaring |
---|---|
topp (toppen av objektet) |
Standardverdi ved fotogrammetrisk registrering. For de fleste objekttyper er dette også presisert på objekttypen |
fot (foten av objektet) |
Benyttes ved fotogrammetrisk registrering kun for objekttyper der det er presisert at høydereferansen skal være foten av objektet eller terrenghøyde. |
D.1.3. Egenskaper på flater med heleid geometri
For objekttyper som er modellert med heleid flategeometri (finnes f.eks. i Arealbruk, BygnAnlegg og Naturinfo) må egenskaper knyttet til geometrien som datafangstdato og kvalitet representere hele flateobjektet. Man har ikke som tidligere muligheten av å splitte avgrensningen og sette ulik kvalitet/dato på ulike deler av avgrensningen.
Dersom deler av (avgrensningen til) en flate har redusert kvalitet bør dette gjenspeiles på flatas kvalitetskoding. Ved ajourføring av en flate settes ny datafangstdato på flateobjektet.
D.2. Fotogrammetrisk ajourhold
Ved fotogrammetrisk ajourhold sender oppdragsgiver eksisterende data i henhold til FKB-produktspesifikasjon til oppdragstaker som grunnlag for ajourføring. FKB-dataene oppdateres der det har skjedd endringer slik at fullstendigheten i kartet skal bli tilsvarende som på fototidspunktet.
Merknad: Det forutsettes at eksisterende data oppfyller kravene til stedfestingsnøyaktighet gitt i produktspesifikasjonen. Dersom dette ikke er tilfelle kan det være vanskelig å gjøre en fornuftig ajourføring av dataene. Nykonstruksjon eller oppgradering bør da vurderes.
Fotogrammetrisk ajourhold innebærer i prinsippet følgende operasjoner:
-
Registrere nye objekter der disse finnes i flybildene, men ikke i eksisterende data. Reglene som gjelder nye objekter ved Fotogrammetrisk nykonstruksjon skal da anvendes.
-
I en del situasjoner må eksisterende objekter splittes eller sammenføyes i forbindelse med fotogrammetrisk registrering. De generelle reglene for Unik identifikasjon av kartobjektene i FKB skal da legges til grunn.
-
-
Verifisere at objekter som er registrert i eksisterende data fortsatt er i tråd med datagrunnlaget/flybildene. For disse objektene skal egenskapen VERIFISERINGSDATO oppdateres, men forøvrig skal objektene ikke endres. Se eget kapittel om Bruk av datoegenskaper i FKB.
-
Det presiseres at for objekter som verifiseres ved ajourføring skal lokalid beholdes uendret.
-
-
Slette (fjerne fra fila) objekter som finnes i eksisterende data, men som ikke finnes i flybildene.
-
Dersom man er i tvil om objektet fremdeles finnes i terrenget grunnet dårlig innsyn i flybildene så skal objektet beholdes. Det finnes særlige retningslinjer for slike vurderinger på en del objekttyper.
-
Unntak fra/presisering av hovedreglene kan avtales i teknisk spesifikasjon for kartleggleggingsprosjektet.
D.3. Fotogrammetrisk oppgradering
Mens ajourføring dreier seg om å fange opp endringer i terrenget som ikke finnes i FKB-dataene dreier en oppgradering seg om en total gjennomgang av alle data innenfor kartleggingsområdet for å sikre at de er i tråd med spesifiserte krav. Eksempler på oppgradering kan være:
-
Omklassifisering av angitte objekttyper i tråd med nye regler/krav i FKB-produktspesifikasjon
-
Oppgradering av angitte objekttypers geometrirepresentasjon (f.eks. hvis det bestemmes at en objekttype skal endres fra HREF fot til HREF topp)
-
Påføring av egenskaper på alle objekter av en objekttype
-
Påføring av høydeverdier på alle objekter av en objekttype
-
Tilpasning av angitte objekttyper for å skape konsistens mellom datasett (f.eks. en omkoding av eksisterende data i FKB-Veg for å skape konsistens med vegnettet)
Reglene for oppgradering er ikke beskrevet i fotogrammetrisk registreringsinstruks og må avtales spesielt i det enkelte kartlegginsprosjekt der dette er aktuelt. Se Oppgradering for en generell beskrivelse av oppgradering av FKB-data.
D.4. Geografisk avgrensning av kartleggingsområder
Ved fotogrammetrisk datafangst angis prosjektområdet datafangsten skal skje innenfor ved hjelp av et definert avgrensningspolygon. Følgende håndtering gjelder dersom ikke annet er angitt:
-
Avgrensningspolygonet utformes av oppdragsgiver på en slik måte at bygninger (og sekundært andre typer flate-objekter) i minst mulig grad deles.
-
Avgrensningspolygonet leveres tilbake fra oppdragstaker sammen med dataene.
-
Nærmere retningslinjer for ev. justeringer i avgrensningspolygonet fra oppdragstaker avtales i det enkelte prosjekt. I så fall skal justert avgrensning leveres tilbake sammen med dataene. Justering kan for eksempel være aktuelt dersom man ønsker å konstruere objekter innenfor hele flyfotodekningen eller man ønsker å få registrert alle bygninger som deles av avgrensningspolygonet
-
-
Nye flate-objekter skal deles av avgrensningspolygonet
-
For flater med delt geometri benyttes en fiktiv avgrensningsobjekttype langs avgrensningspolygonet som det i følge datamodellen er lovlig at kan avgrense flata.
-
For flater med heleid geometri angis det ikke på noen spesielle måte at flata er avgrenset av avgrensningspolygonet, men avgrensninga til flata skal være helt sammenfallende med geometrien til avgrensningspolygonet
-
-
Flate-objekter som verifiseres i forbindelse med ajourføring skal ikke splittes.
-
Dersom det ikke kan verifiseres fotogrammetrisk at hele objektet fortsatt finnes så skal objektet ikke endres (merkes med VERIFISERINGSDATO) selv om store deler av objektet er innenfor prosjektområdet.
-
-
Nye kurve-objekter skal konnekteres til avgrensningspolygonet
-
Eksisterende data utenfor prosjektområdet som naturlig skal knyttes sammen med nye kurve-objekter splittes og knyttes til nye objekter i siste punkt som ligger innenfor avgrensningspolygonet
-
-
Kurve-objekter som skal verifiseres i forbindelse med ajourføring splittes i siste punkt som ligger innenfor prosjektområdet. VERIFISERINGSDATO påføres kun på den delen som i sin helhet ligger innenfor prosjektområdet. Dersom objektet krysser prosjektavgrensningen gjentatte ganger kan hele objektet verifiseres uten splitting, forutsatt stereodekning
Lisensvilkår
Lisens
Denne standarden er gitt ut under norsk lisens for offentlige data (NLOD).
Du har lov til:
-
å kopiere og tilgjengeliggjøre
-
å endre og/eller sette sammen med andre datasett
-
å kopiere og tilgjengeliggjøre en endret eller sammensatt versjon
-
å benytte datasettet kommersielt
På følgende vilkår:
-
at du navngir lisensgiver slik lisensgiver ber om, men ikke på en måte som indikerer at disse har godkjent eller anbefaler deg eller din bruk av datasettet
-
at du ikke bruker dataene på en måte som fremstår som villedende, og heller ikke fordreier eller uriktig fremstiller dataene
Med den forståelse:
-
at data som inneholder personopplysninger og er taushetsbelagt ikke er omfattet av denne lisensen og ikke kan viderebrukes
-
at lisensgiver fraskriver seg ethvert ansvar for informasjonens kvalitet og hva informasjonen brukes til